• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 63 subscribers
  • Views 361 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: Device echoes SPI command which appears as actual data

Dan C.
Prodigy 30 points
Part Number: BQ76952

Tool/software:

We use an S32K1 MCU to communicate with the BQ76952 over SPI (with CRC). Sometime when we transmit a command, the BQ76952 merely echoes the command back. This causes issues because it gets interpreted as real data (address matches and CRC is valid). As an example, here's the sequence we follow to read a sub-command with data:

  1. Write sub-command LSB ID to 0x3E
  2. Write sub-command MSB ID to 0x3F
  3. Wait for the 'operation time' period as defined in Table 9-2 in the TRM
  4. Read the length of the response form 0x61
  5. Read the data from 0x40 for the expected length
  6. Read the checksum from 0x60

Now, this process randomly fails at step 4 because the BQ76952 echoes the command back and we receive the wrong data length as a result i.e.

MOSI: 61 FF 13, MISO: 61 FF 13

As the received address (61) is what we're expecting and the CRC is valid, it is not possible for the MCU to know this is not 'real' data. I understand the BQ76952 may not be 'ready' but in that case it should respond with FF FF 00.

Are you able to provide any insight to help me understand what is happening? Is there anything we can do to resolve this apart from adding an unnecessarily long delay for step 3?

Thank you.

  • 0
    TI__Genius 17795 points

    Hello Dan,

    If you are just trying to read a subcommand with data, you do not need to read the length of the response from 0x61. Section 2 Subcommands of the software guide explain a bit more regarding this. Section 5.6 RAM Register Read Example: Enabled Protections A in the Software Development Guide shows an example of this process in SPI.

    Table 9-2. Command/Subcommand Operation Time gives an approximate time required to complete an operation; however, it can vary depending on the system operation at the time. It is recommended to incorporate a retry scheme from the host processor to handle communication errors or delays that may occur during operation.

    This previous post may also be useful: 0x60 checksum and 0x61 data length.

    Best Regards,
    Alexis

  • 0 in reply to Alexis_H
    Prodigy 30 points

    Hi Alexis,

    My approach verifies the checksum after the read so for that reason I do need to read the length. Note, I am following the 'most efficient approach to read data from a sub-command' as specified in section 3.1 of the TRM.

    Assuming that the checksum verification is not necessary since I am using SPI with CRC, I believe I would still have an issue. The underlying problem is the BQ76952 echoing back the command rather than responding with FF FF 00 to indicate it is not  ready. So instead of me 'receiving' the incorrect length, I'd get incorrect data for the register 40 if the BQ76952 echoes the 40 FF 54 command.

    I have used a longer delay for now before requesting the length but this is sub-optimal. It's a real shame the retry mechanism is not reliable.

    Thanks

    Dan

  • 0 in reply to Dan C.
    TI__Genius 17795 points

    Hello Dan,

    Dan C. said:
    My approach verifies the checksum after the read so for that reason I do need to read the length.

    Maybe I’m misunderstanding something, however, the checksum is calculated over 0x3E, 0x3F, and the buffer data. It does not include the checksum or length in 0x60 and 0x61 so you shouldn’t need the length of the response from 0x61.

    Dan C. said:
    The underlying problem is the BQ76952 echoing back the command rather than responding with FF FF 00 to indicate it is not  ready. So instead of me 'receiving' the incorrect length, I'd get incorrect data for the register 40 if the BQ76952 echoes the 40 FF 54 command.

    Do you mind sharing your logic analyzer file showing this?

    Best Regards,
    Alexis

  • 0 in reply to Alexis_H
    Prodigy 30 points

    Hi Alexis,

    You're quite right in that the length is not need for the checksum calculation, I wasn't very clear in my description. I read the length to avoid having to read all 32 bytes of the data block in order to save time (we need to read data from the BQ76952 at high rates so try to save time wherever possible). The checksum is then calculated over 0x3E, 0x3F and only the number of bytes read from the data block which is given by the length.

    Regardless, the real issue is the echoed command, below are a few examples of what I mean:

    Failed command 1:

    Data MOSI Data MISO
    BE 85 0B 60 7C 86
    BE 85 0B BE 85 0B
    BF 00 8C BE 85 0B
    BF 00 8C BF 00 8C
    61 FF 09 BF 00 46
    61 FF 13 FF FF 00
    61 FF 13 FF FF 00
    61 FF 13 61 FF 13

    Failed command 2:

    Data MOSI Data MISO
    BF 00 8C BF 00 8C
    61 FF 13 BF 00 8C
    61 FF 13 FF FF 00
    61 FF 13 61 FF 13
    --- retry ---
    BE 85 0B 61 FF 13
    BE 85 0B BE 85 0B
    BF 00 8C BE 85 0B
    BF 00 8C BF 00 8C
    61 FF 13 BF 00 8C
    61 FF 13 61 FF 13
    34 FF 5E 61 FF 13

    Failed command 3:

    Data MOSI Data MISO
    BE 83 19 3B FF 4E
    BE 83 19 BE 83 19
    BF 00 8C BE 83 19
    BF 00 8C BF 00 8C
    61 FF 13 BF 00 8C
    61 FF 13 61 FF 13

    Here is an example of a successful command:

    Data MOSI Data MISO
    BF 00 8C BE 85 0B
    BF 00 8C BF 00 8C
    61 FF 09 BF 00 8C
    61 FF 09 FF FF 00
    61 FF 09 FF FF 00
    61 FF 13 FF FF 00
    61 FF 13 61 06 F2
    40 FF A8 61 06 F2
    40 FF A8 40 00 5B
    41 FF BD 40 00 5B
    41 FF BD 41 00 4E
    60 FF 06 41 00 4E
    60 FF 06 60 7A 94

    and another:

    Data MOSI Data MISO
    BE 85 0B 60 7C 86
    BE 85 0B BE 85 0B
    BF 00 8C
    		 BE 85 0B
    BF 00 8C FF FF 00
    BF 00 8C FF FF 00
    BF 00 46 FF FF 00
    BF 00 46 FF FF 00
    BF 00 8C BF 00 8C
    61 FF 13 BF 00 8C
    61 FF 13 61 06 F2
    40 FF A8 61 06 F2
    40 FF A8 40 00 5B
    41 FF BD 40 00 5B
    41 FF BD 41 00 4E
    60 FF 06 41 00 4E
    60 FF 06 60 7A 94

    Thanks

    Dan

  • 0 in reply to Dan C.
    TI__Genius 17795 points

    Hello Dan,

    Thank you for clarifying and sharing those examples. Adding a longer delay time after sending the subcommand and before reading 0x61 is an option that may help as you've stated before.

    Something else I did notice from what you shared is that you didn’t read 0x3E and 0x3F to check if the subcommand has completed operation yet after Step 1 and Step 2 as stated in Section 3.1 Direct Commands and Subcommands in the TRM. If reading 0x3E and 0x3F returns 0xFF, this indicates the subcommand has not completed operation as well. This response only applies to subcommands that return data to be read back.

    By doing this step, you can ensure the subcommand has completed operation instead of waiting for a potentially long enough delay that can vary on the subcommand and host processor. Would you like to try that instead to see if that works better for your case?

    Best Regards,
    Alexis

  • 0 in reply to Alexis_H
    Prodigy 30 points

    Hi Alexis,

    I'll give that a go,  I thought that once the device echoes back the write command it indicates that it has been processed. Does that mean I will not  need any delay/wait period before reading the length afterwards?

    Thanks

    Dan

  • 0 in reply to Dan C.
    TI__Genius 17795 points

    Hello Dan,

    Dan C. said:
    I thought that once the device echoes back the write command it indicates that it has been processed

    When writing to 0x3E and 0x3F, if the device echoes back the write command, I believe the command has been received/processed, but not necessarily the subcommand has completed operation/data being ready.

    Dan C. said:
    Does that mean I will not  need any delay/wait period before reading the length afterwards?

    Correct, if you are reading 0x3E and 0x3F continuously to see if it returns 0xFF or reflects the command.

    Best Regards,
    Alexis

  • 0 in reply to Alexis_H
    Prodigy 30 points

    Hi Alexis,

    Thanks for the confirmation. I've implemented the 0x3E & 0x3F read and it has both resolved the command echo issue and reduced the time between setting the sub-command ID and reading the data length.

    Thanks

    Dan