• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 63 subscribers
  • Views 792 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.

BQ27426: Clarification on BlockDataChecksum

Nicolas Venturo
Intellectual 810 points
Part Number: BQ27426

Hello,


I'm trying to get the RAM save/restore code for the BQ27426 working (in particular, I'm trying to store the State and Ra subclasses to nonvolatile memory, and then write them back to the device). I think I got the process working correctly, but I'm still not sure on how the checksum works.

The Technical Reference says BlockDataChecksum holds the LSB of the sum of the 32 bytes currently addressable from 0x40 to 0x5F, and that I should write the complement of the checksum (255 - (checksum & 0xFF)) after writing to transfer that data to RAM. There are examples in that document that show how to calculate the new checksum by reading the old one and reading that old data that is going to be replaced, but I'd like to avoid that, if at all possible. I'd also like to be able to check that the data that I've read is correct by calculating a checksum on my end.

I'm specially unsure as to how this all works because both the State and Ra subclasses are less than 32 bytes long (31 and 30, respectively). Should I add padding and write/read the whole 32 bytes? Do I need to wait for some time after setting the subclass and offset for the data to be readable and the checksum to be calculated, or can I start reading/writing right away? Right now I'm reading the 31 bytes of the State subclass immediately after setting the subclass and offset, calculating the checksum (by adding all of the bytes and then taking the LSB), and it doesn't match the value of BlockDataChecksum.

Thanks!

  • 0
    TI__Guru 60846 points
    The easiest method is to read the whole 32-byte block into a local buffer, modify the data in this buffer, calculate the check-sum for the whole buffer, write back all 32 bytes and then write the check sum.

    Subclasses may have additional parameters that are private (not documented in the TRM) so you will always have to read a whole block if you want to calculate the check-sum for the whole block.
  • 0 in reply to Dominik Hartl11
    Intellectual 810 points
    By 'block', do you mean 32-bytes?

    I'm not modifying the contents of the subclass, I just store it periodically in nonvolatile memory and later restore it if the gauge suffered a power loss (if the ITPOR bit is set). In that case, could I simply assume the actual length of the subclasses is actually a multiple of 32 (a whole number of blocks), so 32 bytes for State and 32 bytes for Ra, and read/write the whole 32 bytes? Or should I read the whole block, only store/replace the bytes documented in the Technical Reference, calculate the checksum over the whole block, and write back?
  • 0 in reply to Nicolas Venturo
    TI__Guru 60846 points
    Yes, a whole block is always 32 bytes.

    subclass = command 0x3E
    block# = command 0x3F

    A subclass can be a multiple of 32 bytes. If you just want to store a subclass, I'd read all blocks from that subclass (number of blocks = highest offset in TRM / 32) and when it's time to restore the subclass, write the blocks (together with the check sum for each block).
  • 0 in reply to Dominik Hartl11
    Intellectual 810 points
    Thank you so much Dominik.

    One last question, although a bit unrelated: after noticing that the ITPOR bit is set, and restoring previously saved State and Ra tables, do I still need to set the correct Chem ID? If so, does it matter whether I do it before or after updating the tables? I'm wondering because the TRM states that changing the Chem ID updates RAM values. Do I need to wait for a bit after changing the Chem ID before restoring the rest of the values?
  • 0 in reply to Nicolas Venturo
    TI__Guru 60846 points
    After a power on reset, please send the command to select the ChemID before (!) updating the Ra and State subclasses. The gauge will have to pull the correct chemistry tables from ROM so if you don't send the ChemID command then the gauge will use the default tables which (assuming you don't use the default Chemistry) won't be compatible with your cell.