Checksum computation for UART bootloader

[LLouf]

Hello,

I'm testing to flash a new firmware using an ESP32 on an STM32F103xC, using the application note AN3155. There seems to be an error in the computation of the checksum that must be included in all messages.

The documentation states that :

1. checksum: received blocks of data bytes are XOR-ed. A byte containing the computed 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.
2. For each command the host sends a byte and its complement (XOR = 0x00).

Then, a bit later, the following is said for the "Read memory" command :

The host sends bytes to the STM32 as follows:
 Bytes 1-2 : 0x11 + 0xEE

So that should be pretty obvious from this example that if you XOR the two bytes (read command & checksum), you don't get 0x00 but 0xFF. Testing it with my setup, that kind of command is acked by the STM32, though later (when sending the address to read), if you send data with the checksum like what is described in the beginning of the application note, the message get NACKed (I tried changing the order of the bytes of the address, no success).

A similar question has already been asked here https://community.st.com/s/question/0D50X00009XkWHdSAN/errata-for-an3155?t=1552315663186 and closed, but unfortunately without any answer to it, and the AN3155 hasn't been revised with a correction.

Any way to fix that (so, fix the doc) ?

[Tesla DeLorean]

But is that even a checksum? That's the command byte and it's complement, and doesn't contribute to the sum.

[LLouf]

I know, for the command the wording is bit weird. But I guess the underlying mechanism is the same, except it is not accurately described. I guess a more accurate description would be "the complement of the XOR of all bytes in the message" (so if there's only one byte in the case of commands, you take its complement).