cancel
Showing results for 
Search instead for 
Did you mean: 

STM32N6 FSBL address confusion

ZainNoman
Associate II

Hi I have been looking into the boot process for stm32n6 and was unclear about a few things. For booting from external flash the steps are as follows 

1. build your app's bin file. The app should be built with the vector table at the start and the linker script should have a base address 0x34180400
2. Add the header using the signing tool
3. Upload the code to flash using extloader

This is correct right? The second step is what confuses me. I use the command 
STM32_SigningTool_CLI -bin Project.bin -nk -of 0x80000000 -t fsbl -o Project-trusted.bin -hv 2.3 -dump Project-trusted.bin
as indicated in https://github.com/STMicroelectronics/STM32CubeN6/tree/main/Projects/NUCLEO-N657X0-Q/Templates/Template
I did a hexdump on the generated Project-trusted.bin file and I have the following questions regarding it 
1. The base header and padding header have a combined length of 576 bytes (0x240). After that the app starts. This doesn't line up with the linker script or UM3234. The linker script suggests an offset of 0x400, UM3234 mentions an offset of 512 bytes 0x200. Also, is the whole binary copied to the RAM or just the payload?
2.  from UM3234, at offset 0x70 there should be the entry point for the program. so that should be the Reset_Handler correct? i.e. the second element in the vector table. This isn't matching either. At offset 0x70 of the header i have 34180fcd, while the app's binary has the reset handler at 0x34180f70. arm-none-eabi-nm mentions that at 34180fcc i have the default handler.

1 ACCEPTED SOLUTION

Accepted Solutions
ZainNoman
Associate II

Sigh.... Turns out i needed to add the --align option to the STM32_SigningTool_CLI. This was mentioned in an article i think. So now the generated images are working and the entry point is also correct. . Using the cube programmer i was able to verify that the header is indeed also copied to RAM. The UM3234 offset of 512 bytes is wrong then I guess

View solution in original post

1 REPLY 1
ZainNoman
Associate II

Sigh.... Turns out i needed to add the --align option to the STM32_SigningTool_CLI. This was mentioned in an article i think. So now the generated images are working and the entry point is also correct. . Using the cube programmer i was able to verify that the header is indeed also copied to RAM. The UM3234 offset of 512 bytes is wrong then I guess