Debug launch appears to end up in bootloader

[Tim Butler]

I have a NUCLEO-L4R5ZI board with an STM32L4R5ZIT6P MCU. I have been successfully building and debugging using CubeIDE 1.9.0 with a USB connection to the onboard ST -LINK debugger. However, I've suddenly encountered a situation where after the debug load, break at main() and continue sequence, the program doesn't execute and control looks to have ended up in the system boot memory. For example, when suspending execution, the traceback shows:

0x1fff16da

0x1fff2c76

I was wondering if anybody might have any ideas as to what could be happening.

A few more data points:

• The Flash is being correctly programmed by the debugger. If I power cycle the board, letting it run without the debugger, the program executes properly.
• I can do a debugger attach on the running program and successfully debug.
• This happens on more than one board.
• This appears to be somewhat random, as I have older projects that don't fail.

Thanks and best regards,

Tim Butler

[Tesla DeLorean]

It's one of these STM32 that latches options at power up, not normal resets.

Make sure SystemInit() is properly mapping SCB->VTOR because the default is zero, and whatever is mapped into the zero address space, which can be ROM, RAM or FLASH, but is likely ROM in this case. Or ensure the mapping is to FLASH via SYSCFG map settings.

There's also perhaps an issue with the Option Bytes on these L4R5's but I'll need to dig up a specific cite.

[Tesla DeLorean]

Probably the PEMPTY issue

https://community.st.com/s/article/Empty-check-mechanism-on-SMT32

https://community.st.com/s/question/0D53W00001PxcHZSAZ/can-you-have-too-many-peripheral-init-functions

[Tim Butler]

To summarize, the problem entails occasional cases where the CubeIDE debugger programs and boots into Flash (as expected), while the memory at address 0 is remapped to system memory instead of Flash (unexpected). I've verified 2 workarounds:

1. Define the preprocessor symbol USER_VECT_TAB_ADDRESS, which causes SCB->VTOR to explicitly point to the vector table in Flash. This avoids the transfer of control into the bootloader vector table which is incorrectly mapped at address 0.
2. Change the option bit nSWBOOT0 to 0. This, in conjunction with option bit nBOOT0 = 1, results in the memory at address 0 being correctly remapped to Flash.

Regards,

Tim

[Tesla DeLorean]

ST really should have used a symbolic link for the vector table rather than the define, that way the linker could do it's job and you wouldn't have to edit multiple files when it changed.

Historically the CMSIS methodology was to set this in SystemInit(), along with initializing the FPU, and external memories, etc. so that the startup code could then initialize the statics properly. Then came HAL/Cube..

[trzeci]

I had the same problem.
I did set a vector table address of bootloader in both run and debug configurations of an application being run under the bootloder.
It works.