Problem with system bootloader on NUCLEO-H503RB using UART interface

[mvladic]

I'm using system bootloader to write to flash memory on NUCLEO-H503RB evaluation board. The interface used is UART. I received ACK confirmation (0x79) for every command I sent: UART bootloader activation (0x7F), Extended Erase Memory (0x44) and multiple Write Memory commands (0x31). I'm writing about 58K to flash. When I checked what was actually written I found out that only first 600 (!?) bytes are correct but all the rest bytes are 0xFF's! Do you have any idea what the problem is? Only thing I noticed that first 600 bytes are actually vector table (150 pointers x 4 byte per pointer). So, vector table is written well, but all other bytes are not, even though I received ACK confirmation for every command.

Some background information. I'm doing this programming with other STM32 microcontroller (to be precise it is STM32H765). I'm reading HEX file from the SD card. I checked every step of programming. Did I read correct bytes from the file on SD card? Yes. Did I write each and every byte using Write Memory command? Yes. Did all the addresses sent to this commands are correct? Yes. Etc. I'm executing one Write Memory command per 16 bytes (this is how HEX file is organised, 16 bytes per line). I also tried to send the wrong CRC and indeed I received NACK as expected. So it seems every step of programming is correct yet only 600 bytes of ~58K is actually written correctly.

P.S. Sorry for the long post.

[Tesla DeLorean]

HEX files can be sparse, and the data addresses misaligned. Double check the alignment, or put a .BIN on the SD Card and try that more directly.

Don't recall the H5 details, but perhaps assume 64-bit (8-byte) alignment of addresses and write width.

Check with STM32 Cube Programmer in UART mode.

[mvladic]

You are right! There is a change of address alignment in HEX file from the address 0x8000258. Before that address it is 16 byte alignment and after that address it is 8 byte alignment.

On STM32H5, address alignment must be 16 byte according to AN2606 (https://www.st.com/resource/en/application_note/an2606-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf).

I moved to BIN file as you suggested. HEX file was my first idea which I used successfully on another project several years ago and never questioned it. BIN file takes more than twice less space and doesn't need to be parsed on the fly. This solved my problem.

Thank you for your help!