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: I2C - permanent lockup (update)

Part Number: BQ76952

Tool/software:

I made a post previously on this issue, see  BQ76952: I2C - permanent lockup

To summarize - I am running a test where I send a read-subcommand (0x0003 = hardware num), from an MCU, repeatedly to test the stability of the I2C coms. After several hours of this test, the BQ76952 starts NACK'ing bytes - sometimes that subaddr write, sometimes a random data-byte, sometimes the address itself.

---

Since then, I've made a couple of big discoveries that have fixed the inconsistencies - a glitch in the MCU (not a TI MCU) where when I try to send a STOP where it expects an ACK - the I2C peripheral breaks, and I was not sending a true RPT START subcommand, but rather a START-STOP-START-STOP that appears to have made the communications less consistent

---

So I am seeing some new behavior: the BQ76952 coms are swapping from I2C (slow) with CRC, to I2C Fast (no CRC), seemingly randomly. So my question is:

What would make the BQ76952 swap the I2C operating mode? I see that sending the SWAP_TO_I2C, or SWAP_COMM_MODE subcommands will switch the I2C configuration, but I was not sending either of these commands. I see that there is also a timeout functionality - from page 74 of the reference manual:

then the device will reset the communications interface logic if a clock is detected low longer than TIMEOUT

of 5 ms to 20 ms. The bus also includes a long-term timeout if the SCL pin is detected low for more than 2

seconds, which applies whether the Comm Type setting includes timeouts or not.

When this timeout happens, does the communication interface of the BQ76952 swap to the setting in the COMM TYPE dataRam register? Are there any other mechanisms by which the BQ76952 might reset its com interface to the setting in the COMM TYPE dataRam register?

---

---

Also - from the previous post the last comment posted to me inquired about rise-time on the I2C, but this was not an issue. While it is true it was slow, the I2C rise/fall times were within spec, and the waveforms during lockup were the same as those during normal communications; I don't have issues with the rise/fall time in the current testing/configuration

- Mike

  • Spent this week testing my fixes, and it looks like this is solved. My problems were some combination of:

    1. some hardware bug with the MCU I was using to send I2C messages (completely unrelated to TI)

    2. Sending subcommands without a Repeat start

    3. The BQ76952 coms config (I2C config) that was running did not match the coms config in the dataRam register, and it was resetting at a point I wasn't expecting, making communications undefined. Making the dataRam register and the running coms config matchmakes this a non-issue