2026-03-04 1:18 AM
There is a problem with STM32 signing tool version 2.21.0. When header version is 2.3 and alignment flag is used, then image length in header is greater by the alignment byte count.
To reproduce:
Create dummy.bin that is filled with 256 bytes of FF's. For example with HxD tool.
Sign it with no keys:
STM32_SigningTool_CLI.exe -bin dummy.bin --type fsbl --no-keys --option-flags 0x80000000 --output signed.bin --dump-header signed.bin --header-version 2.3 --align
View the signed.bin with hex viewer (e.g. HxD) at offset 0x6C which is Image length by UM3234 rev 2:
It is 0x2C0 = 704. This is 448 bytes more than original 256 bytes.
When removing --align flag from signing call, the length becomes correct, but this image is not bootable anymore because STM32N6 Boot ROM expects FSBL image start address to be aligned to 0x400.
I want to use this length field to check during OTA that FSBL upgrade file size and checksum are correct before programming it into Flash. But I wonder how does N6 Boot ROM treat this invalid length? Boot ROM does not know the "file" size in Flash, because there is no such thing as file on raw Flash memory. And if it doesn't have the correct size then it can't calculate correct checksum either. Or does it include alignment bytes into CRC calculation? Or it's ignored...??
2026-03-04 1:28 AM - edited 2026-03-04 1:48 AM
I corrupted bytes in the alignment area and in the middle of the STM32N6 FSBL signed binary, programmed into Flash and Boot ROM happily starts up the FSBL in Flash boot mode (not Development boot). To be sure I did re-power cycles and added printf call with text message that I altered in signed binary, and it prints it out!
I use STM32N6570-DK. MCU public key hashes and RMA password have been written into OTP. No other changes in OTP. Device state is Closed_Unlocked (haven't dared to lock it yet). In this state, doesn't it check checksum?