cancel
Showing results for 
Search instead for 
Did you mean: 

STM32VBT6 bootloader memory alignement

bastienchd
Visitor

Hello,
I am writing a programm for a raspi cm4 to flash a programm on an STM32 using the UART bootloader. The raspi parses some hex file that I want to flash and sends data packets to the bootloader using the 0x31 write command. 
Here is what I have achieved until now:

  • Successfully enable the bootloader and initiate uart communication
  • Erase the user memory (mass erase command)
  • Use the write command and receive an ACK back

When I run the complete programm, no error is returned and no error/nack is returned. I can affirm that the bootloader answers all my requests without exception with an ACK because I monitor the bus with a logic analizer. However, when I compare the memory to the initial hex file I am trying to flash, there are some differences.

Everything is identical up to this part of the hex file:
:04EBD0009E467047A6
:10EBD800000000000000000000000000000000002D
:10EBE8000000000001000000020000000300000017
Starting from the address 0x0801EBD8, none of the bytes I send to the bootloader are written (everything is 0xFF) into the memory, even though it returns acknowledges to all my request.

My guess is that everything before EBD0 is 16bytes-aligned, but because of the 4 bytes gap between EBD4 and EBD8, all the addresses I'm writing at from this point are only 8bytes-aligned. These addresses are apparently invalid and the documentation for the uart bootloader indeed specifies: "No error is
returned when the start address is invalid.
"

I compiled myself the programm on STMCUBEIDE to obtain the hex file. I am surprised that it would provide a file where the addresses are not compatible with my MCU. Furthermore, the documention for the bootloader tells me that the word alignement required for my MCU is 8 bytes:

bastienchd_0-1734452030508.png

All of this is very confusing to me. My idea of a solution would be to manually pad the memory from EBD4 to EBD8 with 0xFF to keep the size of my packets a multiple of 16 but this doesn't sound right. 
Any suggestions or remarks regarding my reasoning?
Thank you for your help.

 

3 REPLIES 3
bastienchd
Visitor

PS: the bootloader version returned by the get cmd (0x00) is 0x31

bastienchd
Visitor

Okay so I ran a few more tests and it seems that even 16bytes alignment isn't valid. The only packets that are written correctly in the memory are the ones with 32-bytes alignment. The reference manual of the STM32H7 series (RM0433) states:
"A program operation consists in issuing write commands. The embedded flash memory
supports, for each memory bank, the execution of one write command while one command
is waiting in the write command queue. Since a 10-bit ECC code is associated to each 256-
bit data flash word, only write operations by 256 bits are executed in the non-volatile
memory.
Note: The application can decide to write as little as 8 bits to a 256 flash word. In this case, a
force-write mechanism to the 256 bits + ECC is used (see FW1/2 bit of FLASH_CR1/2
register)."

Which indeed seems to indicate that the correct alignement is 32 bytes. Is there any way to modify this?
If not, the application note AN2606 needs to be modified.

bastienchd
Visitor

Otherwise, is there a way to modify the settings of the STMCUBE application builder to obtain a hex file that is directly compatible with the memory alignment of my MCU?