Other Parts Discussed in Thread: BQSTUDIO
I'm writing a set of c functions that can interface with the fuel gauge part and ran into some undocumented behavior I'd like some clarification on.
I followed the flow chart in figure 1 of the document SLUUAP7 (attached to this post for convenience) and captured the I2C bus transactions to verify that I was faithfully following the recommended communication pattern. I also made sure I was using the 100kHz bus data rate as recommended by the datasheet. I was able to verify that my communications were conforming to the expected behavior outlined in the figure, but had issues when comparing my expected checksum to the value retrieved by reading from the IC. Specifically, the step at the end of the block labeled "Steps to verify RAM update completed correctly" in the figure I've mentioned. No matter what values I was using the returned byte from the part was always 0x00, and so when comparing my expected new checksum against the reported checksum the comparison would fail. Per the recommended design flow this would configure a retry of the whole update, trapping the code in an endless loop.
I couldn't understand what the issue was but eventually found that if I added a delay before I read the checksum from the part (I'm using a 1s delay after writing 0x00 to 0x3F) that I was able to read back the expected checksum and it matched what I had calculated. From what I could tell this behavior is undocumented. What minimum delay value should I be using here to ensure that the part is able to correctly report the checksum value back to my program?
Thank you,
Don