NavX stuck in firmware update mode

We’re competing this weekend and our navx has decided to give us fits. The firmware update light is solid red and it won’t reset to normal operation. Any suggestions? Thanks!

> solid red

If the 3.3V LED is the only LED that turns on after resetting after firmware downloading (when the navX-MXP is NOT in firmware update mode), then the firmware image that was previously downloaded has become corrupted. Reasons for this can include that .hex file w/the firmware in it has been corrupted; it’s also been reported by one user that their USB cable was faulty and that was leading to problems during this process.

It’s also possible (if the red 3.3V LED is the only LED that turns on) that the board is still in firmware update mode, waiting for firmware to be loaded.

If you think corruption is possible, I’d recommend one or more of the following:

  1. Try a new USB cable
  2. Re-download the navX-MXP software, run the install and try downloading the firmware again.

Do be sure that you are entering firmware update mode correctly: firmly hold down the “CAL” button and then apply power to the navX-MXP; this is the only way it can enter firmware update mode. If navX-MXP does correctly enter firmware update mode, when you connect over USB, you will see in the windows device manager under USB devices there should be listed “STM Device in DFU Mode”.

At this point, the navXFirmwareUpdater (after you select a .hex file to download) will have the “Update navX-Model Firmware” button enabled. This button is only enabled if the navX-MXP is in firmware update mode and connected over USB, so it’s another way to verify it’s in this mode.

Once started downloading firmware, the progress display should indicate that the download is in progress. Once 100% completed, then you can click on the currently-loaded navX-Model Firmware Version tab and get a display of the currently-loaded version.

So I ended up having to use my desktop computer at home with a different cable, and it finally flashed. I’ll have to fire it up in the morning when we get back in the pits and see if it’ll be stable. We managed to get a loaner navx and it worked beautifully, we’ll have to see if ours is going to be stable now.

Thanks for the suggestions :slight_smile:

Regarding stability issues, is your sensor mounted parallel to the floor? If not, you will want to review the Omnimount calibration.

So we never got around to testing it out… we ran on the loaner all weekend. We’re going to order a replacement just to be on the safe side for Houston. It is mounted pretty close to dead center of the robot, parallel to the floor. The trouble seemed to be that sometimes when we would push code, it would cause it to freak out, and we’d get checksum errors in the console log (I may be remembering incorrectly, I wasn’t the one troubleshooting the issue directly and my memory sucks). This happened to us repeatedly in Arizona North, and the only way to get our navx to function properly again was to reflash it. And it was only a matter of time before it started throwing that error again. We didn’t run into this at all with the borrowed unit, despite us pushing code updates numerous times. So I don’t know if we just got a flaky unit or what…

Send an email to [email protected] to get an RMA started. Kauai Labs will be in the Robot Service Center in both Houston and St. Louis, so we can bring you a replacement board then, or we can get a replacement shipped out to you as soon as the RMA is started. We look forward to analyzing the board you’ve got to see what might be the problem.