• State Answer Suggested
  • Locked Locked
  • Replies 15 replies
  • Answers 1 answer
  • Subscribers 34 subscribers
  • Views 3554 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.

SensorLib and MPU-9250

Giuseppe Iellamo
Prodigy 220 points

Hi all,

has anyone succedded in using the mpu 9250 with the tivaware sensorlib, I've tried to dig into the regmaps and they seems to be very similar apart from the reset value of MPU9150_O_PWR_MGMT_1.

But when I try to use it via the mpu9150, consfiguration completes without I2C error, but i don't get any INT from the device...

  • 0
    TI__Guru**** 244400 points
    Hello Giuseppe,

    Did you check the I2C transaction? Also perform a readback of the registers to verify all values are programmed as expected.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 220 points
    I2C transaction seems good, but I'm writing a quick readback of all register to verify everything is as expected.
  • 0 in reply to Giuseppe Iellamo
    Prodigy 220 points
    IT seems that just reading INT_STATUS via I2C restarted all the interrupts..
  • 0 in reply to Giuseppe Iellamo
    TI__Guru**** 244400 points
    Hello Giuseppe,

    Generally these devices have an open drain Interrupt, which requires an external pull up. Is that installed?

    Secondly, reading the INT_STATUS to start an interrupt is not normal behavior. There must be something else as a trigger too.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 220 points

    Hi Amit,

    the interrupt pin is configurable open drain or push pull, so I've not installed the pull up (I did the same with the 9150 that worked like a charm).

    Regarding reading the INT_STATUS (only once) you're right I don't think is normal behaviour, but I haven't understood from the datasheet what else is needed...

    G.

  • 0 in reply to Giuseppe Iellamo
    TI__Guru**** 244400 points
    Hello Giuseppe,

    May be the vendor would be able to highlight if it is a bug or expected behavior.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Mastermind 7015 points
    I think the issue is related to the sensorlib library and how it works.
    I have changed the registers as well, but it get stuck on the MPU9150AppI2CWait call after the MPU9150Init

    Amit, does Texas plan to update the library to make the MPU9250 work? Actually the mpu9150 present in the SensorHub is deprecated.

    Regards
  • 0 in reply to PAk
    TI__Guru**** 244400 points
    Hello PAk,

    Unless the Sensor Hub Booster Pack is updated for MPU9250, we do not plan to add the support in the examples.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Mastermind 7015 points
    Well, MPU9150 is in EOL state....better now than late!!
  • 0
    Prodigy 30 points

    Just got this working myself.  To get the 9150 library code working with the 9250, required roughly:

    -the 9250 has a different value (0x01) in the power management register after reset, so this is the value that should be checked for in the read states after reset.  A preprocessor macro to switch based on the chip you intend to use could change between values if you also use his code with the LaunchPad SenseHub, which still uses the 9150.

    -the 9250 is more particular about timing between commands, and the time between power-up and sending the first command.  The simplest way to address this is a busy wait before the first write (the one to reset the device), and then a busy wait after each I2C write in the 9150 code.  If you're crunched for time at power-up, you'll need to make more substantial changes for interrupt-based waits with one of the timers.  I would guess this won't be a problem when reading the data (it wasn't at the sample rate I used).

    -the 9250 may be particular about the order of the initialization commands; a re-order of the initialization state machine seemed to help some lingering issues.  An order that works is:

    -reset

    -wait for reset to complete

    -write clock preference to power management register (optional if the default clock is ok)

    -gyro config

    -accelerometer config 

    -config (to set up the lpf for the gyro)

    -accelerometer config 2 (to set up lpf for accelerometer)

    -sample rate divisor

    -I2C master enable and wait for external sensor

    -I2C slave delay 

    -I2C slave setup (both read and write slaves)

    -interrupt config and enable

  • 0 in reply to Derek Niederhut
    Mastermind 7015 points
    Would you mind to share some code?
    I think it will be easier for everybody.
  • 0 in reply to Derek Niederhut
    Guru 47900 points
    May I applaud your willingness to present your findings - especially in such clear detail.

    It may be useful if you described the name/number of different functions with which you succeeded. (I'm "blind" to this particular device -and most always, "Devil is in the detail..."

    Thanks for the caring post...
  • 0 in reply to cb1
    Prodigy 30 points

    Sure; the changes were all made within TivaWare\sensorlib\mpu9150.c

    The initial write to the power management register, that got a delay after it, is in MPU9150Init(); it's the call to I2CMWrite() after setting up the buffer with the power management address and the reset value.

    The state machine code is within the MPU9150Callback() function and writes in the same manner; that is, set up buffer with starting address and data value(s), call I2CMWrite() with the appropriate size.  Each state that writes to a register got a delay afterward (the state that reads the power management register does not need a delay as it handles the inability to read from the chip already).  In addition to the re-ordering, I added a couple steps (to correspond to the bullet points in my answer); the init chain wound up being: reset, reset wait, power management, gyro & accel config, gyro filter config (skipped if MPU9150 because it's the same register as accel filter config), accel filter config, sample rate config, user control, slave delay, slave 0, last.  Note that the states, in keeping with the practice in the existing code, refer to the action that should have just completed; that is, slave 0 is where you land in the callback after having already written to slave 0, and so you write to slave 4 and then change to the last state.  Where the 9250 register addresses or values differ from the 9150, the appropriate numbers can be found in the 9250 register map, which is on Invensense's website.

    A trivial implementation of a busy wait is just a volatile variable in a decrementing loop.  If you want to be really exact, you can write it in assembly and count clock cycles, but in my application C code and an educated guess was good enough.

  • 0 in reply to PAk
    Prodigy 30 points

    Can't.  

    First, the changes were made on top of TI's source code, which for example is subject to export license control; putting it on the internet for anyone to see would be a violation of its license agreement.

    Second, the changes were made as part of paid work, so even if TI agreed to alternate licensing terms, my hands would still be tied.

    I believe I've shared enough knowledge--particularly with the additional clarifications in response to cb1's request--that even novice C programmers should have no trouble producing something that works themselves.

  • 0
    Prodigy 200 points
    Hi to all!

    I know this is not an answer on Giuseppe´s question, but I would like to catch the opportunity to talk to TMS and MPU-9250 users.
    There is a open source robotic autopilot project based on the TMS570 and MPU-9250 (for testing). So if I looking for peoples with both expertises.
    The project website: adapilot.likeabird.eu

    If you are interested in this project, drop me a message.

    Cheers,

    -Jarno