BQ76952: I2C - permanent lockup

Hello Mike,

When you say locked out, do you mean as in the SDA is stuck low? Just to make sure, does your MCU have clock stretching? Could you share a logic analyzer file of this? What subcommands/commands are you sending?

Have you tried generating 8+1 clock signals in attempt to release the bus? This previous forum post may be able to assist you: How to Inform an I2C Target to Release the Bus.

Best Regards,
Alexis

Hello Alexis,

I have some answers to your questions, as well as some further background:

Alexis_H said:

as in the SDA is stuck low

I have gone through this previously in development, and I have the solution implemented from the forum post you shared - the 8+1 clock-cycle SCL toggle. So - this was a previous problem I encountered that I have fixed, I appreciate the suggestion though

Alexis_H said:

When you say locked out,

I mean that the BQ will not respond at its I2C address. I am attempting to read the "DEVICE_NUM" subcommand. The microcontroller attempts to send 0x08(I2Caddr) + 0x3E + 0x10 + 0x00 but it never gets past 0x08(I2C addr) and gets a "NACK" (see below)

Alexis_H said:

Just to make sure, does your MCU have clock stretching?

My MCU does have clock-stretching, it is configurable. In the above capture you can see the microcontroller clock-stretching, but when I disable the clock-stretch (microcontroller sends a "STOP" and releases the bus immediately on NACK), and SDA and SCL lines both return High, the BQ76952 still will not respond to further communication attempts

Here is what the logic analyzer looks like, when this communication is functional. It will look like this for about a day or two until the BQ76952 stops acknowledging

Note that this is out of order, the communication goes 3 -> 1 -> 2. Also note, there are CRC bytes in these messages

This is the I2C communication-string I am sending, on loop:

i2c addr (write) + 0x3E + 0x01 + CRC + 0x00 + CRC

wait 40ms

i2c addr (write) + 0x3E

i2c addr (read) + 0x3E + data0 + CRC + data1 + CRC... etc.

I am sending this communication string on loop between the microcontroller and BQ76952 for days, but eventually the BQ76952 will no longer acknowledge at its address

To clarify - when the BQ76952 is in this "stuck" scenario (not acknowledging) both the SCL and SDA lines are HIGH when the microcontroller isn't actively sending an I2C byte

An update - when the BQ76952 is getting stuck, it has inconsistent behavior:

Sometimes it nack's its I2C address (ie. Write 0x08 will be nack'd), othertimes it will respond to this initial address and NACK the first data-byte as seen above. But it is never able to run a communication, and will continue nack'ing any communications sent until there is a full power-on reset

Hello Mike,

I see that you are sending/writing the 0x001 Device Number subcommand on loop. Are you also reading the data from the data buffer at 0x40 as well when this occurs? Have you seen this same behavior when trying other commands (direct or subcommands)? 

Best Regards,
Alexis

Hello Alexis,

Alexis_H said:

Are you also reading the data from the data buffer at 0x40 as well when this occurs?

I am reading this data, starting at address 0x3E - the datasheet explains that 0x3E and 0x3F will be populated with the subcommand (0x0001 in this case) when data has been successfully written to the data registers, so I'm checking those first to verify that the data is accurate. I am also reading the data-registers at 0x40 when this is happening

Alexis_H said:

Have you seen this same behavior when trying other commands (direct or subcommands)? 

This is a test specifically for the integrity of the I2C coms, so I'm using a command that will always return a constant value, as a test. In the regular code I am reading and writing many other direct, sub, and dataRam commands; is it useful to vary what commands I am sending? I can vary it up, if so

I think I may have found an issue with crosstalk on the SDA/SCL lines, though:

Pink = SDA, Blue = SCL here. VIL is ~0.8 to 0.6V, and I have seen it go as high as 1.2V which is out of spec (1.0V max). VIH was also significantly out of spec (~1.8V) but this capture is after adding 200pF to SDA/SCL pins. I'm going to experiment with adding different capacitances and changing the pullups if necessary, but it could just be a hardware issue with the lines. I'll post an update when I've sorted this out

Hello Mike,

There isn't a specific command that would need to be tested as much as just trying to understand the specific situation further. I'm wondering if the device's address or communication mode was potentially shifted which is why the device kept on NACKing until a full power-on reset was done which resets the device back to its default. 

Mike Stallone said:

I'm going to experiment with adding different capacitances and changing the pullups if necessary, but it could just be a hardware issue with the lines

That is also possible. Please let me know if you find anything else. We typically recommend/use 10kOhm pull up resistors for the SCL/SDA lines as shown in Figure 5-10. Schematic Diagram Pin Configuration from our EVM User Guide. 

Best Regards,
Alexis

Hello Alexis,

Alexis_H said:

There isn't a specific command that would need to be tested as much as just trying to understand the specific situation further. I'm wondering if the device's address or communication mode was potentially shifted which is why the device kept on NACKing until a full power-on reset was done which resets the device back to its default. 

That would be interesting, in further testing I have seen the system spontaneously resume communications after several hours of nacking. I have also seen partial responses, as seen 2 messages ago, where the BQ76952 responds to its I2C address, but then NACK's the subaddress, and this happens consistently

Alexis_H said:

That is also possible. Please let me know if you find anything else. We typically recommend/use 10kOhm pull up resistors for the SCL/SDA lines as shown in Figure 5-10. Schematic Diagram Pin Configuration from our EVM User Guide. 

I originally had 10k resistors on the circuit, but the rise-time on the SDA/SCL pin were both far out of spec for 400kHz I2C, somewhere around 1us. I swapped to 1.5k resistors which pushed my risetime below the 300ns spec. 

Adding 100pF of capacitance to the lines isn't helping the crosstalk between SDA and SCL lines, and 220pF increases my risetime too much. I'm going to swap to 100kHz I2C, and swap back to 10k resistors, see if that remedies things. I will continue posting updates

Thank you,

Mike

Hello Mike,

Do let us know what you find! The rise times looked awfully slow in the I2C capture you had, that would definitely have an effect.

Best Regards,

Luis Hernandez Salomon