BMA423 lockup

[MikeMelbot]

Hi,

I'm interfacing a BMA423 with an nRF52810. The chip is working in i2c mode at address 0x18 (SDO line to GND).

I'm using the API library provided at https://github.com/BoschSensortec/BMA423-Sensor-API

The first time I ran the code, calling bma423_init() was successfully able to communicate with the chip and read the chip ID. But when calling bma423_write_config(), the chip accepted a few dozens of 8-byte chunks, but at some point, it stopped responding (doesn't ACK the I2C address or pulls the bus down anymore). Now bma423_init() fails every time.

The worst part is that this situation is persistent. I couldn't get the chip to respond anymore.

What I tried:

• I tried I2C address 0x19 or other commands with no luck.
• I hooked up a logic analyzer. The ACK bit after the I2C address and R/W bit is indeed 1 (NACK). No other signs of life at the other end.
• I reproduced the issue with another board.

More info:

• SDA and SCL both seem to have the proper logic levels.
• INT1 and INT2 are both connected to 2 MCU pins configured as inputs
• The CSB pin is tied to VDD
• The chip is working at 3.3V
• The I2C bus is working at 100KHz
• It responded the first time until some point in the transmission of the config file (on both boards) and then seemingly locked up permanently.

We're on a tight deadline so any support would be greatly appreciated.

Thanks in advance,

Mike

[MikeMelbot]

Self-reply:
I still don't know why the config file transfer is failing, but fortunately what was causing it to appear permanent was a decoupling cap that kept the chip powered on for a long time over power cycles, which makes much more sense.

[MikeMelbot · Accepted solution]

After some trial and error the problem was that I was splitting the I2C write access into 2 I2C transactions (1st: write register address without stop condition, 2nd: write data (single byte or burst) with stop condition). This doesn't always work.
Now I buffer the reg address + data to write and do the write access in one single transaction. This works every time.

Sometimes it's good to document and explain one's progress to question what is usually taken for granted, get new perspectives and try different stuff. Most of the time the cause of the problem pops up by itself.

[o_o]

Hi Mike,

I'm glad you solved you issue quickly. In this case, the first debugging step would be to validate your system with the specifications of the datasheet. There is a diagram showing the required protocol to use on the i2c bus.