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: Corrupted CC2 current measurements

Part Number: BQ76952

Tool/software:

We are using the S32K144 processor to communicate with the BQ76952 over SPI. We read the CC2 current every 10ms and have noticed that randomly the received data appears to be corrupted/wrong.

With the battery idle, we expect the current to be 0A +- a few mA. This is indeed what we read most of the time shown by the SPI logs below:

(note, 0x55 is the transmitted dummy value)

1. CC2 measurement 0A

MOSI MISO
3A 55 D7 3B 00 6E
3A 55 D7 3A 00 7B
3B 55 C2 3A 00 7B
3B 55 C2 3B 00 6E

2. CC2 measurement -1mA

MOSI MISO
3A 55 D7 3B FF 9D
3A 55 D7 3A FF 88
3B 55 C2 3A FF 88
3B 55 C2 3B FF 9D

3. CC2 measurement 1mA

MOSI MISO
3A 55 D7 3B 00 6E
3A 55 D7 3A 01 7C
3B 55 C2 3A 01 7C
3B 55 C2 3B 00 6E

Occasionally however, the received data is 0xFF00 or 0x00FF as shown below:

1. CC2 measurement -2.56A

MOSI MISO
3A 55 D7 3B 00 6E
3A 55 D7 3A 00 7B
3B 55 C2 FF FF 00
3B 55 C2 FF FF 00
3B 55 C2 FF FF 00
3B 55 C2 FF FF 00
3B 55 C2 FF FF 00
3B 55 C2 3B FF 9D

2. CC2 measurement 2.55A

MOSI MISO
3A 55 D7 3B FF 9D
3A 55 D7 3A FF 88
3B 55 C2 FF FF 00
3B 55 C2 FF FF 00
3B 55 C2 3B 00 6E

These measurement glitches appear for a single measurement at a time and occur randomly. It seems almost as if the read request comes whilst the CC2 registers are being updated causing incomplete data being returned. Do you have any advice on how to avoid this issue?

  • Hello Dan,

    0xFF00 usually indicates to the controller that the outgoing buffer was not updated by the internal logic before the transaction occurred. Section 9.3.1 SPI Protocol in the Technical Reference Manual explains more about this.

    0x00FF is unusually. Can you provide a logic analyzer file of these transactions as well?

    Best Regards,
    Alexis

  • Hi Alexis, I've attached the complete SPI log. I understand that FF FF 00 indicates the device is busy and data was not update, which is why I keep repeating the request until the device responds with real data (register address 3B, data, valid checksum). What I find interesting is that the device responds with FF FF 00 on the second byte of the request (i.e. register 3B) and not the first (register 3A).

    Thanks

    spi_log_01.csv

  • Hi Alexis, I believe I've fixed the problem. I changed the retry mechanism to retry the entire command rather than just the current transfer. I.e. if the device reports FF FF 00 on the second byte of the read transfer (e.g. register 3B) then I start again and request the first register (3A) followed by the second. I feel the documentation should provide a clearer explanation of this behaviour.

    spi_log_02.csv

  • Hello Dan,

    I’m glad you figured out a solution. I think what was likely happening was you were reading the first byte of the measurement --> the measurement changes --> and then you were trying to read the second byte of the new measurement.

    Best Regards,
    Alexis