About embeddedavenger

embeddedavenger · ‎09-27-2023

Three years ago, I was given a custom prototype board with a BMI160/BMM150, with the MAG sitting on the IMU AUX interface. And I got the pair working, which for this discussion means I could read MAG data through the IMU. This year that prototype board is being turned into a product. And the BMI160 has been replaced by the BMI270. And I can no longer read anything from the MAG. Or rather, every attempt to read a MAG register leaves a zero in DATA_0. After reading the three specs (150, 160, 270) way too many times, I put scope probes on the SCL and SDA lines between the 270 and 150. And it looks like the I2C address byte is being nack'd. My first conclusion was that the ground connection to either SDO or CSB was no longer a connection. So I tried 0x11, 0x12, and 0x13 as addresses. No luck. (I was desperate enough to then try every address from 0 to 127. No luck there either.) So I'm looking for some ideas about why the AUX interface does not work for me. I don't think it is relevant, but I'll include that my interface to the IMU is SPI rather than I2C. And yes, I can read and write the BMI270 registers, and get ACC and GYR data from the BMI270. But before I go, ... One of the things I discovered while reading those specs too many times was that the 270 datasheet states (in two different places): The auxiliary interface is fully compatible with sensors supporting I2C fast-mode-plus (fm+) and which do not require clock stretching. For operating the device with sensors supporting only I2C fast-mode (fm), please contact your regional Bosch Sensortec sales representative. Whereas the 150 datasheet never mentions fast mode plus. It does state: The BMM150 supports I2C standard mode and fast mode OTOH, there are plenty of web pages out there from people who are using the 270/150 pair. So maybe they will work together. And the 270 datasheet specifically mentions the BMM150 as an example of a sensor that can be used on the AUX interface. Which seems an odd thing to do if they are not compatible. Does anyone out there have some illuminating insight for me? Thanks.

embeddedavenger · ‎10-01-2020

I know all the software/firmware folks out there will find this hard to believe, but ... After letting me stare at this problem for almost a week, my hardware engineer decided to look at the problem as well, with a second board. And, of course, it all works on that board. The likely culprit is not software, but a solder connection on the board I am using. So I apologize for bothering the world with a problem that was never going to be solved by a software change.

embeddedavenger · ‎09-28-2020

I have been given a board designed in-house with a BMI160 and BMM150. I started working on the BMI160, and can read ACC and GYR data from it. So I moved on to add MAG data to that. Following the example code in the READme.md file of the BMI160 driver package, bmi_aux_init() calls config_aux_settg(). config_aux_settg() calls config_sec_if(), which sends the normal mode command and sets IF_CONF to specifiy the secondary interface as a magetometer. I can see the PMU status change to show the MAG in normal mode, and can read 0x20 out of the IF_CONF register. So I am pretty sure that went well. Next, config_aux_settg() will call bmi160_config_aux_mode(). This reads MAG_IF[1] (reg addr 0x4c), then sets bit 7 to enable manual mode, loads bits 1:0 with dev->aux_cfg.aux_rd_burst_len, and writes it back out. The example code in the READme.md file sets dev->aux_cfg.aux_rd_burst_len to 2, which is a burst length of 6. I don't get that, particularly in manual mode. But I don't think it is the cause of my problem. And again, I can read back the register and get 0x82. For me, that is the high point. At this point the example code starts to read and write BMM150 registers via the BMI160. For me, all those transfers fail, and all in the same manner. Am I2C transfer has a start phase and an 8-bit data phase that includes a 7-bit slave address and a R/W bit, followed by the slave device acknowldging that address by pulling the data line down during a final clock transition. That acknowledgement bit is where things fail for me. Every transfer the BMI160 attempts to the BMM150 stops when the acknowledge bit is high. The other odd part of this is that the attached picture of the scope (data on top, clock on bottom) is what every transfer attempt looks like. Which is to say, the R/W bit is always low. Even when I am doing a manual mode read attempt. Even when the BMI160 is in auto mode, reading the MAG 25 times a second. Does anyone have any clues for why I can't seem to complete a single I2C transaction between the BMI160 and the BMM150? Any help will be greatly appreciated. Thanks. William Carroll

Bosch Shared

About embeddedavenger

BMI270-to-BMM150 I2C nacking address byte

Re: I can't make a single I2C read or write between the BMI160 and BMM150

I can't make a single I2C read or write between the BMI160 and BMM150

About embeddedavenger

BMI270-to-BMM150 I2C nacking address byte

Re: I can't make a single I2C read or write between the BMI160 and BMM150

I can't make a single I2C read or write between the BMI160 and BMM150

Still looking for something?