Debug session erases more FLASH than expected

[CTapp.1]

I've got an STM32G431 project that uses half of the FLASH (64K) for a boot loader and half for an application.

I can successfully load both of these programs using STM32CubeProgrammer, but I am not able to debug the boot loader in STM32CubeIDE as the application was being erased when starting the debug session (which is configured to download the code when it starts).

The Console output shows the following when the debug session starts:

Memory Programming ...
  File          : ST-LINK_GDB_server_v0z2LC.srec
  Size          : 64.00 KB 
  Address       : 0x08000000 

Erasing memory corresponding to sector 0:
Erasing internal memory sectors [0 31]
Download in Progress:

This correctly shows load boot loader's FLASH address, and the erase command shows the expected page ranges (corresponding to the first 64K of FLASH).

I am actually developing the code that will be responsible for erasing the application as part of the boot loader, and simply have the boot loader call the erase routine when it starts up so that I don't need to trigger the erase action each time. It appears as if this happens when the debugger starts, which makes me think that the target is started at least once between the code being uploaded and the debugger stopping at main() - so the program executes at least once before the debugger takes control.

Is this behaviour expected?

I've now modified my code so that I have to trigger the erase within the debugger (as I should have done in the first place, but I was being lazy)!

I'm using version 1.18.1 under macOS.

[urbito]

Can you also share both linker script files?

[TDK · Accepted solution]

The program starts 3 times total, the first two for 500ms or less, before the third one starts with the debugger. That's the nature of STM32CubeIDE debugging. You can put a HAL_Delay(500) in there if that behavior is unacceptable.

[CTapp.1]

Thanks for confirming.

I'm not using the HAL, but I'll find a way of delaying the startup during development (system is fully operational in ~50mS when in service, so I'll make it conditional).