Nav-X error - Cant get readings


Last year we successfully used our Nav-X MXP during competition. But after upgrading the Firmware to the newer version(3.0.314) we were unable to read any sensor values.
After booting all lights turn on for 1s, then only the 3.3v led turns on with the CAL led slowly flashing. This happens with the sensor connected directly to the roborio and trough usb to a pc.
Im also unable to get any readings from the NavXUI. When connected to the roborio i get the following error message on the Test window vi:<ERR>
CRC mismatch 1 =/= 255.

<b>Complete call chain:</b>

I have attached a print from the test window. We have already tried to reflash the new Firmware and go back to the older firmware, but the error remains the same.
Any input on this would be greatly appreciated!

It looks like you are getting CRC errors. I think the CRC errors are a red herring.

The clue here is that per your description the two green LEDs (S1 and S2) are not solid on (after the first second of startup).

The secondary clue is that I believe you are getting no data at all - a permanent failure. The CRC timing issue is a sporadic failure, not a permanent failure.

With a permanent failure (in which case the S1/S2 green leds are not both lit during normal operation), there will be no messages sent by the navX-MXP because it can’t talk to the onboard MPU-9250 at all. And that means there’s likely no response from the navX at all when an SPI request occurs. Which of course will be interpreted as a CRC error.

What you need to do is run the Factory Test Procedure ( In particular, you need to confirm that the two green S1/S2 leds are working properly.

The other validation to perform is whether the navXUI (connected via USB to a PC) works. If the two green S1/S2 leds don’t work, navXUI won’t work either. At that point, we’ll have confirmation of the problem.

It’s possible something went south during the firmware update and you need to reattempt it. This can occur if the hex file is corrupt, or if the transmission of the complete hex file is interrupted during the firmwmare update process.

If after reflashing the firmware again the problem still persists, you should contact for a replacement.

Thank you,


Thanks! We have tried to flash the new firmware again from other computers but it didn`t showed any effect. The NavXUI appears to detect the board, but shows the attached message. From what i read on their website it looks like the board might be stuck on the omnimount setup.

My team has been trying to use the navX-micro connected through 1 of the USB ports on the roboRio, but has consistently been getting errors and no readings. We are programming in LabVIEW. The error we have been seeing reads:

Error 1055 Property Node in>>>Robot Main.viLabVIEW: Object reference is invalid

We believed that this was a communication reference issue, and that we were selecting the wrong type of communication on the VI, but we have since tried multiple combinations of settings and have not been able to solve the issue.

We have updated the firmware on the navX and have also re-downloaded & installed the newest libraries as of 1/29/17.

I attached images of the code we have in Robot Main and Teleop. Any suggestions?

Teleop navx.PNG

Teleop navx.PNG

Can you please post the results of verifying the USB serial port binding, as described on the “troubleshooting”]( page?

The USB serial port must be correctly bound in order for any USB serial device to work w/the RoboRIO.

Also, reviewing the following may help shed some light:

  • Which RoboRIO USB serial port are you connecting to?

  • Is anything plugged into any other RoboRIO USB serial ports?

OK Here is the run down on the USB. For the RoboRio you have to designate what port you are talking to. Here are some pictures that should help with the setup. If this does not help please let us know.

Port Drawing.fw.png

Port Drawing.fw.png

Port Drawing.fw.png

Thanks for the responses!

So we made sure that we have USB 2 selected in Robot main because we have it plugged into port 2, but we still get the same error. We have a LifeCam HD-3000 plugged into the first USB port, so I don’t know if that is what is screwing us up or not.

I attached a picture of what we get from the Roborio dashboard. I am not clear on how to bind the USB port–could you elaborate?

Hi Eric,

I did some testing and was able to get the navX-Micro USB-connected along with the Microsoft LifeCAM HD 3000.

However, if “USB 2” is selected, communication to the navX-Micro USB doesn’t work.

Here’s what I tested that does work:

navX-Micro USB connected to RoboRIO Rectangular USB Port 1, LifeCam in USB Port 2. LabVIEW navX USB selection: USB 1. Works.

navX-Micro USB connected to RoboRIO Rectangular USB Port 2, LifeCam in USB Port 1. LabVIEW navX USB selection: USB 1. Works.

So I believe the solution is to simply specify USB 1 in the navX-AE LabVIEW Library; the WPI Libraries are apparently intelligently selecting the second USB port if it can’t find a USB serial device in USB port 1.

In talking w/Thad House who works on the WPI Serial Port code, USB 2 is only valid for use if another USB Serial device is connected to USB 1. Since the Microsoft LifeCAM HD 3000 is not a USB serial device (based upon what is displayed in the RoboRIO Web Dashboard) this means USB 2 should not be used. I’ll write up some clarification on this on the navX-MXP/navX-Micro websites.

Hope that helps,

  • scott

Thanks again for the response!

We have tried both USB 1 and USB 2, in addition to physically unplugging the camera (while we are using the Navx-micro) and still get the same as error as was posted above. Any other suggestions?

Here are a few suggestions:

  1. I found during testing of the USB2 option (which based on our testing is not working as expected currently) that after attempting to use USB2, it was required to reboot the roborio in order to get things working again. It’s as if when USB2 is used, something gets in a bad state that requires a reboot to clear. So if you haven’t you might try rebooting the RoboRIO and then re-testing with just the navX-Micro in USB slot 1.

  2. To make sure the navX-Micro is completely healthy, you can verify the two green (S1 and S2) LEDs on the board are lit during operation. If they are not both on during operation, there is a problem w/the board itself.

  3. if 2) succeds, next use the navXUI application (installed when you run the setup program). This would entail connecting the USB cable from the navX-Micro to a Windows PC and verifying that you get a correct reading from the sensor as displayed in the navXUI display.

  4. If 2) or 3) above fails, we’ll be happy to replace the board for you.

  5. If 2) and 3) both work, then there’s something particular to your configuration limiting USB communication. Perhaps it’s the USB cable, perhaps it’s the RoboRIO USB connector. You can check both of these by using the LifeCAM in the slot you are wanting to use the navX-Micro, and the USB cable you were using w/the navX-Micro, and verify that works correctly.

  6. If that’s still not working, you have the option in this case to use the navX-Micro I2C interface instead, as described in the navX-Micro RoboRIO installation page.

Make sure that you have your LabVIEW project file open before you try to run your robot I have seen this error when my student try to run the program without starting the project file first.

We are also experiencing CRC errors when connecting to the SPI port on the RoboRio, via an approximately 30 inch long cable. The NavX initially started to give us heading readings then cut out, yet the green LED lights are still on. Any thoughts on what we’re missing?

30 inches is on the outside of nominal for the 2Mhz SPI signal. CRC errors are likely in this configuration.

If you need to have a cable that long, USB is a great choice. The cable is shielded, differential signaling is used, etc. And it has the benefit of providing power even in a stage 2 roborio brownout.

More discussion here:

  1. So we have tried restarting the roborio multiple times
  2. Both green LEDs light up
  3. The board works when plugged into the computer and running NavXUI
  4. So the board is functioning properly
  5. And it definitely looks like a communication issue
  6. When we plug into the I2C ports, the 2 green LEDs do not stay on after startup…

The problem appears to be within the after following the initial error code posted.

If we run robot main, and look at some of the internal errors in the Navx main VI, we see the pictures attached.

Any other suggestions? Thanks for your help!

Navx Error.PNG
Navx Error 2.PNG
Navx Error 3.PNG

Navx Error.PNG
Navx Error 2.PNG
Navx Error 3.PNG

Hmm, Unknown system error from LabVIEW… Do you have another RoboRIO to try? Also, I don’t usually recommend the following, but it might be worth reformatting your RoboRIO, and re-installing the navX-Setup program again. Perhaps something has become corrupted?

> 6) When we plug into the I2C ports, the 2 green LEDs do not stay on after startup…

So, taken together this means the 2 green LEDs work when USB is used, but not I2C, right? The only reasonable explanation for this case is that when the i2C connection was attempted that there was insufficient voltage (most likely) or DC current supplied to the sensor. I would highly recommend you recheck your wiring and try again.

So doing some more digging, it appears that the USB camera creates 2 unknown devices on the Roborio in addition to displaying the LifeCam connection. We believe that it is these two unknown connections that screw up how the Nav-X program tries to find the device.

When we do NOT have the camera plugged in, the 2 unknown errors and the camera link goes away, and we can get readings off of the Nav-X board.

I attached a picture of what we see on the roboRio connections.

Does anyone have any ideas on if we can permanently fix the port that the Nav-X board is looking for as opposed to searching the ports or if there is a way to get rid of the 2 unknowns created by the camera? Thanks again!