2022-04-15 09:13 AM
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:
Thanks and best regards,
Tim Butler
2022-04-15 09:23 AM
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.
2022-04-15 09:52 AM
Probably the PEMPTY issue
https://community.st.com/s/article/Empty-check-mechanism-on-SMT32
2022-04-16 03:59 PM
Thanks much for the references, they pointed to me to a much better understanding of what's going on. Just to reiterate, the issue of ending up in the bootloader only happens when using the debugger to program the flash and launch execution, and does not always occur. Here's what I've found out.
So I can see ways to work around this, but I still don't understand how a debugger launch can boot from Flash, while system memory is mapped to zero. As you mentioned, maybe it has something to do with the way the system latches the boot0 pin and options while under control of the debugger. In the case where system memory is mapped at zero, SYSCFG_MEMRMP:MEM_MODE is zero upon startup, which is inconsistent. However, if I trace HAL_Init() up to the point where RCC->APB2ENR is set, MEM_MODE changes to 1 (as seen by the debugger), which is consistent with the memory mapping.
I have a reproducible success case and failure case, and I observed that the success case requires the debugger to erase 3 sectors and the failure case 4 sectors. Maybe it's a stretch, but it does indicate a timing difference for the debugger launch sequence and might explain an inconsistent latching of reset conditions in certain cases.
Regards,
Tim
2022-04-18 11:11 AM
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:
Regards,
Tim
2022-04-18 11:57 AM
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..