I am having some trouble reading an IMU over I2C via MRAA+Python. I am able to read the altitude, accelerometer, and gyroscope just great! However, I cannot read the magnetometer values from the 9250. Apparently, it integrates an AK8963 sensor within the IMU.
root@edison:~# i2cdump -y 1 0x68
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: ca d3 e3 13 a0 03 cd 80 00 de 00 02 00 67 5c 7f ????????.?.?.g\?
10: 8e c6 a8 00 00 00 00 00 00 00 00 00 00 00 00 00 ???.............
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
30: 00 00 00 00 00 00 00 00 00 00 01 00 44 fd 48 40 ..........?.D?H@
40: 28 17 20 00 aa 00 0a 00 e5 00 00 00 00 00 00 00 (? .?.?.?.......
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
60: 00 00 00 00 00 00 00 00 00 00 00 01 00 00 06 81 ...........?..??
70: 00 00 00 00 00 71 00 ed 3c 00 ec 72 00 22 40 00 .....q.?<.?r."@.</em>
80: ca d3 e3 13 a0 03 cd 80 00 de 00 02 00 67 5c 7f ????????.?.?.g\?
90: 8e c6 a8 00 00 00 00 00 00 00 00 00 00 00 00 00 ???.............
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
b0: 00 00 00 00 00 00 00 00 00 00 01 00 68 fd 6c 40 ..........?.h?l@
c0: bc 18 c0 00 90 00 17 01 06 00 00 00 00 00 00 00 ???.?.???.......
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e0: 00 00 00 00 00 00 00 00 00 00 00 01 00 00 09 00 ...........?..?.
f0: 00 00 00 00 00 71 00 ed 3c 00 ec 72 00 22 40 00 .....q.?<.?r."@.</em>
Apparently, you need to enable bypass/pass-through mode, as per instructions https://github.com/kriswiner/MPU9250/issues/62 here. (Excellent Arduino example code http://www.lucidarme.me/?p=5057 here.) Based on the datasheets below, that should be a simple
root@edison:~# i2cset -yr 1 0x68 0x37 0x02
However, if I run this, i2c goes completely bonkers. I cannot perform any further dumps without I2c producing rows and rows of garbage. I cannot read any further entries or write 00's back to the original register. The only way to clear it is to shutdown the Edison board and disconnect the power.
Has anyone had any luck reading the 9250 IMU with Intel Edison? I see that others have had similar issues (https://github.com/kriswiner/MPU9250/issues/15 here).
Mini breakout board
- Invensense 9250 (located at 0x68)
- Register map (https://cdn.sparkfun.com/assets/learn_tutorials/5/5/0/MPU-9250-Register-Map.pdf here)
- Datasheet (https://www.akm.com/akm/en/file/datasheet/AK8963C.pdf here)
- BMP (located at 0x77)
- Datasheet (https://cdn-shop.adafruit.com/datasheets/BST-BMP280-DS001-11.pdf here)
Sparkfun Logic converter (https://www.sparkfun.com/products/12009 here)
I am powering the IMU at 3.3V and stepping down the SDA/SCL to 1.8V to be read by the Edison. I have not added any external pull-up resisters to the SDA/SCL pins. Given that the accelerometer and barometer work just fine... is that worth trying?
Thanks for your interest in the Intel® Edison platform.
I have been looking through all the links you have posted, there is a lot of information to look at. I don't have the MPU9250 board to test it, however, according to the information I read, the MPU9250 depends on the system processor to manage the initial configuration of any auxiliary sensors such as the magnetometer, so it has an interface bypass multiplexer that connects the system processor I2C bus directly to the auxiliary sensor I2C bus, once the configuration is done the bypass multiplexer should be disable, for more details please look at the https://www.invensense.com/wp-content/uploads/2015/02/PS-MPU-9250A-01-v1.1.pdf MPU-9250 Product Specification (pages 21 and25).
The register you should use to enable the "bypass mode" is the 55 (INT Pin / Bypass Enable Configuration), I'd recommend you look at the https://cdn.sparkfun.com/assets/learn_tutorials/5/5/0/MPU-9250-Register-Map.pdf MPU-9250 Register Map and Descriptions for more details about how to configure the registers.
Additionally, the Sparkfun Logic converter (https://learn.sparkfun.com/tutorials/bi-directional-logic-level-converter-hookup-guide Bi-Directional Logic Level Converter Hookup Guide) has a couple of pull-up resistors to realize bi-directional level shifting so I think external pull-up resistors are not needed.
Hope you find this information useful.
Yermi, thank you for the reply.
Pin 55 [dec] is equivalent to 0x37 [hex]. As is seen on p29 of the data register, enabling the 1-bit should put the chip into bypass mode. So you need to write xxxxxx10 to this register. As 10 in binary is equivalent to 2 in decimal or hex, the i2c terminal commands I posted above are already attempting to do just this.
root@edison:~# i2cset -yr 1 0x68 0x37 0x02
My problem is that after I write this register, the i2c bus goes bonkers. Can anybody help to fix this?
I don't have the MPU9250 sensor to test it, however, I'd like to share these libraries to communicate with the MPU9250, I know you are using Python, but you may find these other libraries helpful:
Hope this information helps.
These are some excellent libraries. I wasn't aware of the UPM library, which also has some great python examples. I can use it to easily read the acceleration and gyroscopic data. It still cannot read the compass values. Same story with the FaBo library.
Yesterday I WAS successful in enabling bypass mode using I2C on a raspberry pi with a different breakout board for the MPU-9250. I then took that (working) breakout board and connected it to the level shifter on Intel Edison... but I got the same outcome. In addition, Edison's internal resisters were originally set to 20k. I tried enabling bypass mode after changing the internal pull-ups to 2k and then 910ohms. Neither of those options let me read magnetometer values either.
So, as I see it, there are 3 potential culprits: Intel Edison, the sparkfun level-shifter, or some combination of these specific breakout boards with the other two. I'm ordering different breakout boards to attempt to change these.
(note that the reviews on the level-shifter indicate that others have successfully used it on edison with other IMUs)
Great to know you found those libraries helpful. Right now it is difficult to say what could be causing that issue, so I would like to know if you have a logic analyzer or an oscilloscope that you can use to measure the I2C signals, it may help us to identify if there is something strange. Also, it would great to know your results when you get the other breakout boards.
I might be able to get my hands on a logic analyzer or an o-scope. Will need to get back to you on that. In the meantime, here is some more info and an update.
I previously neglected to mention that I was using I2C bus 1, not bus 6. I found one post (/thread/59311 here) claiming to have issues related to that, so I will need to do some more research into this.
However, I realized that I had an old Galileo board lying around, so I decided to fire that up instead as a simple test. Sure enough, enabling bypass mode worked beautifully on the Galileo. So, this is my new list of things to try:
1. Alternate breakout boards
2. Alternate busses
3. O-scope/logic analyzer
Regarding the I2C busses, I think you are using the Intel Edison mini-breakout board because of the need to use a level shifter, right? If so, with the mini-breakout board you should be able to use both I2Cs (I2C1 and I2C6); trying to use the I2C6 to know if something change would be a good test. Moreover, if you are using the Edison with the Arduino expansion board, the only I2C available for connecting devices is the I2C6 because the I2C1 is used internally by the Arduino Expansion board and it is not available.
On the other hand, I'll be waiting for the results you get after your tests.
Yermi, I am using the Mini breakout board.
I have run the same steps on Intel Edison using I2C-6 instead of I2C-1. It fails in the exact same way (as expected). Before this command is run, I can view the accelerometer, gyro, and pressure data (using https://www.amazon.com/dp/B01N0L05M2/ref=asc_df_B01N0L05M24991024/?tag=hyprod-20&creative=395033&cre... this chip and https://www.sparkfun.com/products/12009 this logic converter). Once I attempt to enable bypass mode:
root@edison:~# i2cset -yr 6 0x68 0x37 0x02
– the entire I2C bus becomes unreadable.
I removed the chip from the board and tested the exact same board on Intel Galileo + Poky/Yocto, where it worked flawlessly. (I did not use the level shifter.) So the bus has been exonerated, and the problem must be with the interaction between some of the following:
1. Intel Compute Module
2. Mini Breakout Board
3. Level Shifter.
4. MPU 9250
Thanks for the updates. I also would like to know which Edison image you are using, you can find out by using this command: cat /etc/version, I recommend to use the latest one (201606081705), here you can find instructions to flash the image: https://software.intel.com/en-us/flashing-the-firmware-on-intel-edison-board Flashing your firmware, in case you need.
Also, I'd like to see your results using a logic analyzer or oscilloscope to measure the I2C signals, it may help to look at something that we are omitting.
Thanks for the information. Please let me investigate a little bit more and as soon as I have useful information I'll let you know.
Thanks for your patience.
I would like to suggest you to use a logic analyzer and send the I2C data that is making the bus stop root@edison:~# i2cset -yr 1 0x68 0x37 0x02. First do the test without any logic level transistor because what we want to see here is if sending this data is causing the issue and if the correct address is sent. If there is no issue and you can still send data after doing that, it means that the issue is not with the Edison or with the code used. Then run the same test, but now including the level shifter. If everything works, then the issue is not with the level shifter either. In addition to that, you can compare the I2C signals using the Edison and the Galileo boards, and see if there are any differences between them.
From my end it is difficult to do those tests because I don't have that sensor, however, if someone in the community has used this sensor successfully, we will appreciate if they can share their input.
I am going to attempt a new approach. I think I will have the MCU do the interfacing with the sensors and then the CPU can talk to the MCU. However, I am having a tough time installing the SDK (from https://software.intel.com/en-us/node/545143 here).
I have gotten to the "Running Eclipse" section, but there is no mcusdk.exe in my folder. I extracted everything to C:\mcusdk , but mcusdk.exe is not in there. There is a mcusdk.exe in msusdk\bin\all, but it will not launch.
Any clues on installation tips? Also, I could not install Java JRE 7 because Oracle has discontinued it. I did v8 instead.
I would like to know which OS you are using on your PC, also, did you download the Java SE Runtime Environment 8u131 version of the JRE? Did you download and install the latest Cygwin setup program? Have you tried running again the cygwin_setup.bat file?
Yes, I did. I am using Windows, unfortunately.
But I think this question will continue to remain unanswered. Given the news http://hackaday.com/2017/06/19/intel-discontinues-joule-galileo-and-edison-product-lines/ here, I will discontinue my work on this project with Edison. It really is an awesome board, but it was not supported well-enough to achieve dominance in the space. It's a shame really.