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.

BQ76952: SDA changing state after SCL causing illegal stop condition

Part Number: BQ76952
Other Parts Discussed in Thread: PCA9545A

I'm trying to use the BQ76952 with an ATMega2560. I have i2c working with other TI sensors at 400 khz, but as I'm communicating with this device I am getting intermittent issues receiving data. 

I'm using direct commands, to read cell voltages. It doesn't seem to happen on any regular interval, but I can make it through a handful of read cycles before I get the error. I'm reading all 16 values back to back, every 2 seconds.

I've been chasing this in code for a few days and am certain now that it is coming from the battery chip. That rising SDA pulse is causing my mcu's i2c status register to show an illegal start/stop condition.

The chip is fresh from TI. no configuration has been done, no OTP set. The battery status register shows 0x8184 or 0x0184. Is it intended that the chip comes already set to full-access? I would have assumed it comes locked and you have to unlock it but I suppose the intention is that it's unlocked until you decide to lock it down?

Here are logic captures. The timing of the error condition has SDA rising 40 ns before SCL, and has a width of 792 ns.

400 kHz default fast mode. This device is one of only two devices on the output of a PCA9545A MUX with 4.7k pull-up resistors at the MUX. Trace lengths are 6" or less routed on two layers of 2oz copper at 6 mil width.

Logic captures are probed at the output of the MUX, but the analyzer wires are maybe 18 inches long.

I can get scope captures later.

Is there anything immediately obvious I'm missing?

This occurs with cell voltage direct commands as well as the battery status direct command. That's as far as I've gotten.

Good read

Bad read

error condition

  • Hi Jason,

    I do not see anything obvious. Can you try to connect the MCU directly (bypassing the PCA9545A) to see if the issue still persists? The mux has its own timing parameters that I am not familiar with so I do not know if it could present any issue. Does your MCU support clock stretching?

    Regards,

    Matt