Quote:
Originally Posted by Thad House
Do we have any idea if FIRST is going to fix the FPGA bug with SPI and I2C? It was nice finding a workaround, but it would be even better if they would fix the MXP ports.
|
No word on a resolution by NI - it's likely been because we can't give them a reproducible case; Joe Hershberger of NI has indicated suspicion of a lock not being held correctly during opening of the MXP port, but that hasn't been confirmed.
However in testing it's been discovered that the various communication peripherals on the navX MXP are experiencing bus errors sometimes when the RoboRio is starting up (e.g., upon initial power up, and when "Reboot RobRIO" is selected in the driver station, but not when restarting the robot code). In these cases, a few seconds after the reboot occurs (about one in every ten times) I2C circuits on the navX (including - notably - the internal I2C bus which communicates with the MPU-9250) experience bus errors. My suspicion is that problems occur when the robot app opens a MXP port before the RoboRIO FPGA code that manages the MXP port has completed initialization, and the result is the navX MXP experiences random noise during that time. And the fact that an internal (non-MXP) I2C bus is experiencing error implies the noise is on the power/ground which are used to pull up the internal I2C bus lines. I haven't got it captured on a scope yet, but my hunch is there's a noisy MXP ground sometimes during RoboRIO startup.
[These errors can cause navX MXP comm to the MPU-9250 to lockup. The visible symptom of the internal I2C bus lockup is that only one of the two Green LEDs on the navX MXP will be lit up (in normal operation, both LEDs should be on).]
So the reasonable conclusion is that when using MXP-based SPI/I2C, the navX was being exposed to more of these glitches than when using non-MXP communication, and every now and then could no longer talk to the MPU-9250.
The recent navX MXP firmware has added code to detect these bus errors and reset the affected communication peripherals. In testing, we were able to reproduce the error, and demonstrate successful recovery by the navX MXP firmware. Based on that, I believe the latest navX MXP firmware is resilient to these transients. However these transients could impact other MXP devices too, so the plan is to document this and send the findings to NI and to the ChiefDelphi community.
I'll send out a general update to ChiefDelphi once the latest navX MXP firmware has passed all our tests and is ready for release; I'd recommend retesting at that time, believing the above was the root cause for the sporadic startup failures you saw.