• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 363 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

How do I handle MPU9150 failures in the compdcm_mpu9150 example?

Jeff Kenney
Prodigy 180 points

I have a modified version of the compdcm_mpu9150 example code that mostly works but will sometimes hang for unknown reasons.  I'm trying to figure out how to restart the MPU9150 when MPU9150Init or MPU9150DataRead receives an error.  Unfortunately the compdcm_mpu9150 example code just goes into a permanent while loop.  Any ideas for restarting the MPU9150 would be appreciated.

  • 0
    TI__Intellectual 2615 points

    Can you be more specific about the 9150 hanging?  Hangs how?  Doesn't generate interrupts? I2C bus is hung? Doesn't ACK transactions?

    --Miles

  • 0
    Guru 117855 points

    Vendor's Miles gives sound advice - might I add that you may be able to "narrow" the presently, "unknown reasons" by devising a series of carefully limited & strategically timed, "MCU to Accessory board/chip" tests.

    It may be that one particular command - or that the timing of a command - causes notable distress.  Adding this to your knowledge bank often speeds/eases issue resolution.

    We're not told if this is a, "Single board anomaly" - or if this occurs across multiple boards.

    Classic (but may not prove optimal) methods for "restarting" an accessory board/chip are via:

    a) properly timed power cycle of the stalled board/chip

    b) ordering a reset of the stalled board/chip (should that be a board/chip {HW or SW} capability)

    In both cases - it's normal/customary that the stalled board/chip be re-initialized...  And sometimes - in a "hi-rel" situation/environment - we may regularly issue such a, "restart" to insure that, "All is well..."

    "Mostly works" exceeds (famed) "Does not work" - but not by much!  Is "mostly" 95% success, or when transactions are at very low rate, or...  (devil so often "hangs" in such detail...)

    Anything you can devise to "catch" the moment of "hang/stall" will prove useful.  Our group usually data logs the key signals, register contents, and other "suspect" levels, function calls, events which may serve as "hang" co-conspirators.  A review of that logged data will often pinpoint the source of difficulty...