BlueESC Red LED 1, 2, 3 Flashing / Initialization Issue

Hello all,

There have been several threads about issues with the BlueESCs initializing properly when started up. Most of these cases have shown the following:

1. No initialization or unpredictable initialization

2. Flashing red LED, usually 1 flash, then 2 flashes, then 3 flashes

I’ve been looking into this issue. We’ve seen this during our own QC testing a few times but those units are never shipped. We test every ESC several times before it leaves our facility, but this issue seems to be appearing in some units in the field.

My best guess at the cause is an overly sensitive “hardware check” procedure that is run in the firmware at boot. It’s possible that the hardware check could fail under certain conditions.

I found a BlueESC here demonstrating this issue and I uploaded firmware with the “hardware check” disabled. The BlueESC then worked!

I’m including the firmware files with the “hardware check” disabled here for anyone who may be having this issue and would like to try these. I’d recommend testing these with caution! This is not the best long-term solution but will work until we can identify exactly what is causing this issue.

Current solution: Flash with firmware that has “hardware check” disabled.

Here are detailed instructions on how to reflash a BlueESC: BlueESC Documentation (just reflash with blueesc_id0.hex if you are using PWM control)

Please post your feedback here!

-Rusty

blueesc_firmware_2016-02-20_5f53d5f-no-hardware-check (154 KB)

We’ve been having this issue with the BlueESC also. After a number of rounds of bug checking and unplugging and re-plugging things in, it somehow reset a few times. Once it reset, we were able to replicate the error once it was shut off and turned back on again (ie. power cut off and reattached).

We have no idea what we were doing to reset it, any ideas?

And what is the time frame looking like for a longer term fix for this problem?

Hi Daniel,

Okay. Sorry to hear you’re having this issue - have you tried this firmware fix yet?

-Rusty

The motor would not flash the firmware

it sends kkmulticopter

avrdude.exe: stk500v2_ReceiveMessage(): timeout

it finally worked i disconnect pin 2 from arduino then i connected again and it worked thanks for the post

Hany,

Good! Glad you got that working.

-Rusty

Have the same problem, flashed twice, no good. With i2c from uno to T100 w Blue ESC, communicates fine, send speed command of 3, jitters, then runs up over 9000 RPM. More than 1 motor. Any thoughts?

Edward,

The thruster might jitter at a setting of 3 since that is so close to the stopped command and brushless motors usually have a little trouble spinning at very low speeds. The I2C command ranges from -32767 to 32767. What happens when you send 1000 as the command?

-Rusty

Same thing, runs away, over 9000 rpm, it blows fuses now so dead, I have more like this. My kids competition is in 2 weeks.

Edward,

Okay. As far as I know, there’s no way for the firmware to run up like that unless it gets a valid signal. The PWM signal is prioritized so if it recognizes any signal on the PWM wire, it may cause issues. I would strongly recommend connecting the PWM wire to ground on the Arduino if you haven’t done that already. That will eliminate any noise created on that wire.

The I2C signal is digital and it’s unlikely that a valid signal could be sent in error or affected by signal noise.

Do you have the PWM wire connected to ground? If not, you would mind trying that out?

-Rusty

Ok.

At the time Motor with ESC was not connected to any tether. The PWM signal (red wire) right off your ESC was in midair, and i2c wires were only connected off small cable, and power was directly connected to wire with a fuse on the battery (thick black and red). This firmware disable disables hardware checks of the motor and or ESC? Could this be a way? I got a good firmware upload. My administrator is reaching out to you in support email, we have no time.

Ed

Edward,

Okay. I would definitely suggest grounding that PWM signal wire instead of letting it hang free. That may solve the issue.

How long are the I2C wires that you are using from the Arduino to the ESC?

The firmware attached above disables hardware check for cases where the firmware might incorrectly identify a hardware error. That seems to be the case on some issues but I don’t think your issue is related.

Feel free to email me directly if you’d like to. (rusty@bluerobotics.com)

-Rusty

On my test bench, where i was working, the i2c was running, was about 4 to 5 feet. I thought you had a check where you need a good 1500 signal before using PWM/Servo?

The red blinking issue we have is when we use PWM/Servo on the red wire, on the vehicle we use PWM. Since it was not working, I used i2c to check the controller as you get values back.

So, I have other not working motors with the flash issue using PWM/Servo. Really hate to flash them, especially as this has not gone well, and hard to explain to kids.

Do we have any other options here?

 

Ed

 

Hey Edward,

I just wanna know you are not alone. We also have same issue.

We have six thrusters total, pwm works fine on each thruster. I2C also works fine when i only connect one thruster to Arduino each time. But when i have more than one thruster in my i2c configuration, thruster will suddenly jetter and run at high speed. When i had all six connectted together, only two thrusters was recognized and rest would be either runs away or dead. The code on Arduino just tries to grab the address, i do not have motor. set() in my code at all.

The weirdest part is that i had six thruster i2c configuration working just fine on a breadboard back in February. The only thing changed is longer length of wires because we have wet connects and other pin connects now.

@edward - I think the ESC checks for initialization in general. Whether that comes from I2C or PWM doesn’t matter. It can initialize with I2C and then read PWM signals without initialization. That could cause the issue.

If you’re still having issues please shoot me an email at rusty@bluerobotics.com and we can discuss options.

@Rick - Have you tried slowing down the I2C bus to improve communication reliability? The Arduino_I2C_ESC example code has a few lines you can use to slow down the bus. Also please make sure that you’ve got the PWM signal wire connected to ground.

-Rusty

@Rusty, so turns out ground PWM does fix it! thanks for your help! I also wonder what pull up resistance I should use, right now I am using 2 10k resistors and we don’t have any major issue with it, sometimes the data from ESC seems to be little odd, but I assume 10k is the standard resistance for 100 khz i2c bus?

Rick,

Great! Glad that helped. The ESC already has 10K pullups, but that’s pretty weak for I2C so having the extra set of 10K should be fine. I’m not sure of the best pull-up resistance, unfortunately.

-Rusty

@Rusty , I am having a strange problem that may pertain to this thread. When uploading a sketch from Arduino to the thruster, randomly a thruster will spin up to a high speed for a short time. Once the sketch is done uploading, the thrusters ‘initialize’ and all is well. This is very unpredictable and sometimes doesn’t happen at all; when it does happen, it is not always the same ‘rogue’ thruster.

 

James

Hi James,

That’s an unrelated issue. What’s happening is that the Arduino is sending pulses from 1100-1900 µs with “stopped” at 1500 µs. When you reprogram the Arduino, you stop whatever it’s doing. If it happens to be in the middle of sending at 1500 µs pulse, and gets cut off at, say 1000 µs, the ESC will interpret that as a valid signal and will spin in full reverse.

I would recommend disconnecting power from the ESCs before programming to avoid that.

-Rusty

Hi, i got this problem as well when running the thruster, it just stops out of a sudden. I followed the guide but got the same problem as hany , avrdude.exe: stk500v2_ReceiveMessage(): timeout, tried his method but doesn’t work.

Can i ask if i well to use the KKMulticopterTool do i have to install anything before hand ??