How do I get a positive response from the bldr write memory command if it then the data is not properly written at the memory location? And this only happens in one out of dozen devices of the same model.!

[JPatr.3]

Hello,

I am facing a problem for the first time with one device while doing something that has worked perfectly on several (dozens) before of the same model (STM32H755IIT6).

I am updating the firmware of the device with a custom update tool that has closely the same protocol as flashing with the stm32CubeProgrammer, namely at the writing request "0x31".

The problem is that, at this device, a part of the data is not being written, though I get a positive response from the request, when I am flashing the m4, falling after the address 0x08010040 and for several (not always constant) blocks.

Using a saleae, I can see that both using the update tool or the stm32CubeProgrammer, they perform very much the exact same way (only time differences of ms), for the same file even the same information. E.g.:

Request: 0x31 0xCE

Response: 0x79

Request (Address and checksum) e.g.:0x08 0x00 0x00 0x00 0x08

Response: 0x79

Request: data length, data, checksum

Response: 0x79

This is performed with the same content by the two tools and, for the first time, at this device I currently have it only works using the STM32CubeProgrammer and, if I read the memory, I notice that at the m4 there are some addresses where nothing was written when I use the other tool.

I am, therefore, very triggered, first how one tool works and the other does not, and second and mostly, how does the bootloader responds positive if something failed during the write?

Any hints on what could be the problem?

PS.: I also tried checking the part of memory where it fails to write right after writing there, to mislead from any faulty overwrite that could happen later on.

Thank you for time and feedback!

[FBL]

Hello @João Patrício​ ,

As there is no issue with STM32CubeProgrammer, we don't expect to have any issue with STM32 device.

For more details about bootloader, you can refer to the AN2606

Firas

[JPatr.3]

Solved: The only difference on the protocol was that the stm32CubeProgrammer waits 4 seconds after receiving the positive response from the erase, while the tool would start requesting the write right again. Added this 4s and the problem went away. Since the m4 was the last being erased but the first being written, I suspect that this device for some reason is slower on the erasing and is still erasing while I am writing. I find this unexpected, since I understood that the bootloader only gives the positive after the erase is complete.

TLDR: add 4s wait after the positive response (0x79) of an erase request (0xFF 0xFF 0x00) before requesting a write (0x31 0xCE))