Previously I posted a message thinking that there was an error in AN4221 regarding the checksum and whether it should be complemented. However, looking at (for instance) the Write Memory command, I can see that the command byte sequence and the data packets employ different methods. The command is always accompanied by its complement (i.e. XOR 0xFF, or simply ~command in C); for instance, Erase Memory (No Stretch) is sent as 0x45 0xBA. But then the data packets are accompanied by a checksum where all the bytes are XORed together, starting with 0x00 as a base value. E.g. 0x00 0x01 0x00 0x02 has 0x03 appended, per the AN4221 example in section 2.13. The app note describes in section 2 "Communication safety" how for all data packets sent to the bootloader, "a byte containing the computer XOR of all previous bytes is added to the end of each communication (checksum byte). By XOR-ing all received bytes, data plus checksum, the result at the end of the packet must be 0x00." And that's true... if you XOR 0, 1, 0, 2, and 3 together, you get 0.
What is confusing and contradictory is the notation in the Read Memory command, section 2.4, for sending the number of bytes to be read. The flowchart looks normal, it says "Send data frame: number of bytes to be read (1 byte) and a checksum (1 byte)." If you use the previous checksum method, and you're reading 4 bytes (0x04), you'd expect the checksum to be 0x04 also, because 0x04 XOR 0x04 == 0.
BUT... in section 2.4, it lists seven steps, and step 7 says "Byte 9: checksum: XOR byte 8 (complement of byte 8)". This is NOT the same thing! The complement of byte 8 would be 0xFB, and 0xFB XOR 0x04 == 0xFF, not 0 as described elsewhere.
So which is it? I'm assuming it's a zero checksum result, not a bitwise complement. Can someone from ST clarify that step 7 is written out incorrectly?
Dana M.
