Debug mode - Behaviour Debugging vs loading in flash memory in STM32H7

[geek12]

Hi everybody,

I'm working on a board with STM32H7. I want to understand why when I launch the debugger mode with the bootloader program. The program of the bootloader still on the memory flash of the STM32H7 after a restart (turning off the board) and I can then load the binary program (the application program) using the UART. However, when I launch the application program using the debugger mode when I restart the board out of the debugger mode just the bootloader program stay at the memory flash of the MCU and not the application program. Is there any explanation to such behaviour ? Or it's the settings linked to the debbuger mode ?

Thanks for you support.

[KnarfB]

You're not telling what IDE, this is for STM32CubeIDE. There is a Debug Configuration... editor which opens when you press the down arrow near the de"bug" icon. In the Startup tab, a Start Address can be defined. The default is that the debugger does not change the settings in the MCU. But, you can specify a custom start address (of your app) and the corresponding interrupt vector table address here, matching the linker .ld file settings.

hth

KnarfB

[geek12]

Thanks for your reply.

I have checked the settings of the debugger mode for the bootloader program an I find that the debuuger is set to the default start address and the debbugger settings for the app application is set as following : start address to set program counter at 0x08100004 and runs command to set $r13 = *0x08100000

set $pc = *0x08100004. So is there any explanation to this settings ? Thanks for your help.

[KnarfB]

This depends on how your bootloader and app divide the flash (and RAM) and on what you want to debug. In general, you are responsible to set the correct addresses here, matching your boot loader architecture and the code you want to debug.

hth

KnarfB

[geek12]

Thanks for your reply. I have checked my linker file and I find that the partition of the flash memory wich contains the app program starts from the address 0x08100000 and the bootloader app starts from the address is 0x08000000. So why after debugging the program doesn't remain on the flash memory as the bootloader program ? And why the $pc address is equal to *0x08100004 and not 0x08100000 ? Thanks for your help

[KnarfB]

The first word (offset 0) of a binary image contains the initial stack pointer (r13), and the second word (offset 4) contains the address of the reset handler, (which is the first code to be executed.

If you prog is debugged, the debugger is needed to setup sp and pc correctly. Without the help of a debugger, the chip has built-in hardware defaults which are 0x00000000 and 0x00000004. STM32 MCU hardware can map flash or system memory (resident) boot loader to theses addresses. The bootloader should be there.

If you debug the prog, the debugger overrides this.

Boot loader and prog should both remain in the flash. How did you find out that the prog is not? Maybe the debugger has erase the entire flash?

hth

KnarfB

[geek12]

Thanks for these details. I have done many tries and all the time when I flash the board in debug mode with the program of the bootloader and then I turn off the board. I can load after the binary file of the app using the UART (bootloader allows UART loading of the binary file of the app program). However when I flash the board on debug mode using the app program when I turn off the board and then turn on, my board doesn't start the app program and stay waiting on bootloader program.

[geek12]

So is there any way to fix such issue and to force the remain of the app program on the memory flash after the debug ? Which paramaters should I have to modify ? Thanks for your help.

[Tesla DeLorean]

The app is in FLASH, it's not going anywhere

The CM7 core expects a bootable vector table at 0x08000000 not 0x08100000

The boot address should be an option byte setting.

The option byte read needs a power cycle, not a reset.

If you have a CM4 core, that usually has flash at 0x08100000, but the startup of that using usually gated via the CM7 on dual core H7 devices.