Jump to content

[Energia Library] MPU9150 working* with MSP430 and Tiva-C (almost)

Recommended Posts



I managed to port the MPU9150Lib at https://github.com/r...tech/MPU9150Lib to Energia.


I had to make few changes in defines in dmp code, and the provided CalLib, and now it compiles for MSP430G2553, MSP430F5xx, Stellaris Launchpad, and the Tiva-C series (TM4C123) launchpad. CalLib writes to either flash or eeprom depending on architecture.


It has failed for MSP430G2553, due to code size. It compiles for MSP430F5xx although I dont have a board yet to test. I have not tested the stellaris launchpad but I suspect it works, it does WORK on the Tiva-C series launchpad.


Here is the picture of the setup:




On one side I have an arduino nano v3 connected to a MPU9150 module (The cheap GY 9150) and on the other side I have a Tiva-C series launchpad with a sensorhub booster pack. (that contains a MPU9150 as well) and I have hooked up a usbee logic analyzer to i2c (sda, scl) of both mcus


For some reason, it is running slow on the TM4C123 then the arduino. It is supposed to work much faster on the Tiva-C launchpad, but on the contrary it does not. I measured mpu.read() times, and on Energia it wont go less then 50ms, where on arduino I have tested up to 200hz sensor read rates with no problem.


Here are two screenshots from the logic analyzer:






The top two signals are from arduino sda scl, the bottom is the sda(3) scl(3) of the Tiva-C


The MPU9150 is configured to update at 20Hz for both systems. however the i2c bus activity seems quite different. 


I am thinking there might be a problem with the i2c speed on Energia, or that it works different.


I tried to upload the code, but appearently stellarisiti will not allow rar files. I have posted the same thing however in 43oh :

http://forum.43oh.com/topic/5685-mpu9150-working-with-msp430-and-tiva-c-almost/ you can grab the rar file from there.


I will be posting all the code on github later - for now I made a zip file for all.


Best Regards,




Link to post
Share on other sites
  • 3 weeks later...

Hello altineller,

I've tested your code by hooking up a 9150 module (similar to the one you connected to the Nano) to Tiva C. I had to add Wire.setModule(1) to the setup function of the Energia9150.ino file and then it worked, but as you said quite slowly.

The slow speed is probably related to the problem addressed by this pull request for the energia wire library: https://github.com/e...nergia/pull/343

In the energia-0101E0012/hardware/lm4f/libraries/Wire/Wire.cpp file the TwoWire::getRxData and TwoWire::sendTxData both have a delay of 1ms build in. This is probably the cause of the delay you are seeing in the SCL of the Tiva. Moreover, the TwoWire::begin method limits the I2C speed to 100kbps.

I've tested your code also with a modified Wire.cpp file, forcing the speed to 400kbps and removing the delay(1) statements from the getRxData and sendTxData methods. This improved speed a lot, but wasn't stable (communictation with the module stopped at random times). To get it stable I had to add 10micro second delays (delayMicroseconds(10)) to the getRxData and sendTxData methods instead of the delay(1). With this change I could increase the MPU_UPDATA_RATE to 200 and the MAG_UPDATE_RATE to 100, resulting in an average sample time of less then 6ms.

Link to post
Share on other sites

Hello Frans,


If I can reproduce your results, that would make my day. :)


I have progressed a little more in making the MPU9150 work with energia. Which development board are you using? If you are using stellaris, or the tiva-c

there are two resistors, R9 and R10, you have to unsolder them out to get i2c working stable. It was some feature to keep booster packs backwards compatible, connecting the i2c pins to other pins in the mcu, which is bad practice.


I have also the energia from github the latest revision (not 0101E0012 release) but the current development branch. I suggest you do the same.


I also located the delay(1) in the both 0012 and the recent development branch. I will test and play with the delays, and see if I can replicate your results. Also, on forums there is something about dont use delayMicroseconds - there is a better way of doing in tiva-c i believe.


Also I have a question: "forcing the speed to 400kbps" - how did you do this? by defining a TWI_FREQ 400000L ?


The reason why i ported this specific mpu9150 library, is because i have tested many libs, really tested them (i.e. on a physics lab similar lab setup)

and this library works really well. (https://github.com/richards-tech/MPU9150Lib) - With a razor imu, you can get 50hz readings, and it is costly.


I have tested the output of this mpu9150lib, and even without calibration, it works really good. I have done tests like making a wooden cube, aligning a desk to magnetic north, and putting the breadboard on each face of the cube,  (and measuring if it returns to old position, etc.) - Another thing is you dont get gimbal locked with this sensor. I modified the quarternion based vis software for the mpu6050, and tested it does not get gimbal locked.


This example is also using the dmp code, so if we make it work and post code in github that would be a nice gift to the community.




Link to post
Share on other sites

@@Frans I have tested your fix and it works. Making this faster than the arduino. (with a nano i was able to go 120hz max)


I have not seen any problems or glitches at 200hz.


Here are two graphs I made, one at 80hz, other at 200hz averaging 6ms per read.


Look at those periodic spikes in the 200hz test. It is probably some fifo problem.


However it works now, and I will soon make this into a library and post it on github.


Best regards,






Link to post
Share on other sites

@@altineller I'm glad that you get the same good results.

Like you I have the Tiva-C development board. I didn't know about the R9 and R10 resistors, but from what I read those only affect I2C3. For my testing I used I2C1 on pins PA6 and 7.


Also I have a question: "forcing the speed to 400kbps" - how did you do this? by defining a TWI_FREQ 400000L ?


In the file energia-0101E0012/hardware/lm4f/libraries/Wire/Wire.cpp the TwoWire::begin() method calls ROM_I2CMasterInitExpClk(MASTER_BASE, F_CPU, false), which is implemented by the core I2C driver (energia-0101E0012/hardware/lm4f/cores/lm4f/driverlib/i2c.c). According to the comments in that file, the i2c driver implements 100kbps and 400kbps and the speed is selected with the last boolean argument. In the TwoWire::begin() method I therefore simply replaced 'false' with 'true' (ROM_I2CMasterInitExpClk(MASTER_BASE, F_CPU, true)). If this actually increased the speed I cannot tell. I don't have a scope or logic analyser yet.


Best regards,


Link to post
Share on other sites
  • 5 months later...



Any updates on when/where you code will be posted? I'm currently working on a project and have been looking around for libraries to use on my Tiva C Eval board and Sensor Hub BoosterPack setup and it looks like you tested your ported code on the exact same setup successfully.


Thanks! :)

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...