Tool/software:
Good day,
short version: when programming the configuration is it the intended behaviour to get an ACK to the command writing the checksum in case of success and a NACK in case of a mismatch of the checksum and will this behavious be guaranteed in future?
Long version: I'm currently writing to code to use BQ27421 to replace the previously used ic which is going into obsolescence. I'm currently working on the setup part of the chip and in particular I'm trying to set the parameters of the battery and I'm using the flowchart in SLUUAH7 (Quickstart guide) as reference, as well as SLUUAC5C (Technical manual) to double check the informations. My current code flow (pseudo code, insert code is not working so adding as plain text) is:
setupBQ27421() {
1 - Wait for INITCOMP bit to be set set
2 - Unseal (2x control sub cmd 0x8000)
3 - Send cfg update command (control sub cmd 0x0013) and wait for CFGUPDATE bit to be set
4 - Write 0x00 to block data control (cmd 0x61)
5 - Write 0x52 to data class (cmd 0x3E)
6 - Write 0x00 to data block (cmd 0x3F)
7 - Read and print current content (cmd 0x40...0x5F)
8 - Read current checksum (cmd 0x60)
9 - Write updated values (cmd 0x40...0x5F) while keeping track of expected checksum
10 - Write expected checksum (cmd 0x60)
11 - Write 0x52 to data class (cmd 0x3E)
12 - Read checksum (cmd 0x60)
13 - Send soft reset (control sub cmd 0x0042) and wait for CFGUPDMODE bit to clear
}
My doubts are on step 12. According to the flow chart in quickstart guide I should be able to read back the expected value I just wrote however what I read is the original checksum. Apart from that the procedure seems to complete successfully as if I call the function again I will see my updated values in step 7 and the expected checksum I calculated earlier in step 8.
As check I tried to write an invalid checksum in step 10. Doing so I see that the IC will reply with a NACK to the write and procedure will fail (a second call shows the values and checksum were not touched from original values).
What I see contrasts with the procedure indicated in the quickstart guide flowchart (into box "Steps to verify RAM update completed correctly") where it is showed the read back of the checksum should be the same as the value that was just written. Also I could not find the indication that writing an invalid checksum will give a NACK in any part of the manuals. So I wanted to double check that what I see in the expected behaviour and if I use the ACK/NACK of the write as confirmation of a correct procedure the behaviour will not change in future. Thanks for your support
Alessandro Marzocchi
