Intermittent Break at address "0x1fff51f4" with no debug...

My colleague stated that upgrading to CubeIDE 1.6.1 resolved the issue for him. I have not rigorously tested this as I have been out of the office the past few days. I will report my findings after testing a bit.

A few more critical observations. After experiencing the 0x1fff51f4 error I did the following:

1. Disconnect the debugger using the red "Terminate" button.

2. Used STM32CubeProgrammer to read the contents of flash at the start address of 0x08000000. Flash was not erased.

3. Power cycled the board. It boots and runs fine.

This tells me that there is no issue with flashing the code and that the bootloader isn't being executed because the flash is erased.

Also, I tried setting a breakpoint in Reset_Handler() on the first ASM instruction and clicking the "Reset" button. Breakpoint is never hit.

Hello Everyone, thank you for your comments. To clarify:

• My problems only occur when trying to do debug from CubeIDE with STLINKV2. When running the board stand alone it starts correctly every time.
• i use STM32L4R7VIT6 on a custom board.
• Boot0 Pin is tied to GND via 10k
• Flash is not blank. I can read the flash content at address 0x08000000 every time, it is always good
  • the flash content is not mapped to address 0. Instead, the bootloader is mapped to address 0 every other time
• I can read the content of VTOR register. It is always zero at start of debugging
• I can read the memory remap register Syscfg/MEMRMP. It always shows zero, which means, the boot0-pin is correctly sampled, being low. This should result in flash memory being mapped to address zero for flash memory start
• I can read every other time that the memory at address 0 does not show the flash memory content but the bootloader, despite the fact, that Boot0 Pin is tied to zero and Syscfg/memrmp is zero

Hello all,

I am working with STM directly to further investigate this issue. I will update this thread when I get more information from them. ETA mid next week.

Thanks

I have a solution for my situation:

I experienced, that the flash content is every other time is not mapped to 0x00000000 despite the fact, that the memory relocation register indicates, that flash should be mapped to 0x00000000. Every other time at 0x0000 0000 there is bootloader code. The Vector Table register VTOR still sets the Vector Table to 0x0000 0000. If an IRQ occurs, it would jump to bootloader instead of my program.

By setting VTOR to 0x0800 0000, the program runs fine with IRQs.

CubeIDE project settings has an option to set the VTOR register each time, the code starts.

void SystemInit(void)
{
#if defined(USER_VECT_TAB_ADDRESS)
 /* Configure the Vector Table location -------------------------------------*/
 SCB->VTOR = VECT_TAB_BASE_ADDRESS | VECT_TAB_OFFSET;
#endif
 
 /* FPU settings ------------------------------------------------------------*/
#if (__FPU_PRESENT == 1) && (__FPU_USED == 1)
 SCB->CPACR |= ((3UL << 20U)|(3UL << 22U)); /* set CP10 and CP11 Full Access */
#endif

But for this to happen, you need to set a global define USER_VECT_TAB_ADDRESS

This fixes the problem for me. The flash content is still not mapped to 0x0000 0000 each time, but the software starts each debug session properly.

Possibly related thread https://community.st.com/s/question/0D53W00000vQjc5SAC/stm32l4r9-fails-execution-by-going-to-an-invalid-address-for-program-execution

Figured I would provide an update since I see recent activity on this thread. STM still has not investigated beyond reproducing the issue two weeks ago. I ping them every few days and they always tell me they will ping the development team for an update. My next step is to reach out to our local reps and escalate this issue. Stay tuned.

Further observations:

When opening older projects with STM32L4, now I encounter the same problems not starting a debug session other time. We never had this problems in the past. So why do older projects now starting to get problems?

I assume, that the STLINK driver / debugger module in cubeIDE has changed an now shows problems.

I can avoid this problem by switching to open OCD mode.

With open OCD mode, the debugger always starts properly on my STM32L4R7 project. (custom board)

> So why do older projects now starting to get problems?

Updates? Bad idea.

> I can avoid this problem by switching to open OCD mode.

OK so we can now point to... what do you have the problem with, the GDB server?

JW

Hello all,

Just wanted to provide an update so others don't waste any more time investigating. STM has provided me what appears to be a working solution based on a day of testing. I am checking with them to see if I can post it here, or if they plan to release a fix themselves. In short, they provided me new flash loader files for CubeIDE. I will provide an update with more details once I get a response from them.

Derek