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

[DerekR]

Hardware:

MCU: STM32L4R9ZGJ6 (Custom board)

OSPI mapped to address 0x90000000

ST-Link V2

PH3-BOOT0 pin pulled to ground with 10k Ohm resistor.

Software:

IDE: STM32CubeIDE 1.6.0 (Build: 9614_20210223_1703 (UTC)

SDK: STM32Cube_FW_L4_V1.14.0

TouchGFX assets are loaded in OSPI at address 0x90000000 (Probably not relevant to my issue)

STM MCU Option Bytes Configuration in STM32CubeProgrammer:

nBOOT1: Checked

nSWBOOT0: Checked

nBOOT0: Checked

Issue:

Hello,

My issue is that when attempting to debug the MCU in STM32CubeIDE, it often attempts to start at address 0x1fff51F4 with the message "Break at address "0x1fff51f4" with no debug information available, or outside program code". main() is never called because my breakpoint at the top of main() is never hit. To mitigate the issue, I simply press the red "Terminate" button to stop the debug session, then press the "Debug" button to restart, and the program then loads at the correct address and breaks in main(). This happens randomly without any changes to the code, option bytes, or hardware. Yesterday it was happening about 50% of the time, now it's about 10% of the time and seems to change in frequency. I wouldn't mind stopping and restarting the debugger to mitigate, but CubeIDE take roughly 3 minutes to program and connect the debugger so stopping and restarting is time consuming.

Question 1: What could be causing this strange behavior of STM32CubeIDE jumping to address 0x1fff51f4?

Question 2: Does STM32CubeIDE not load the PC (Program Counter) with the application start address and jump to that? Or does it still look at the option bytes / BOOT0 pin to determine start address?

Thanks!

Derek

[Johannes]

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

[DerekR]

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

[Tesla DeLorean]

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

A BKPT instruction? Not sure most debuggers using the FPB/DWT can accurately do a reset and have the registers survive. The more bulletproof solution is to have a code fragment configure/drive a GPIO, or checkpoint via characters on the USART

>>I am working with STM directly to further investigate this issue.

If it gets into the protection and anti-glitching methods, probably not going to get positive resolution.

[Johannes]

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.

[DerekR]

Hey jvisser,

Thanks for the feedback. Hopefully your solution fixes the problem for some. Not sure how you generated your CubeIDE project, but it seems FreeRTOS (And probably non-FreeRTOS) projects generated by CubeMX 6.1.1 and later default to this. In Core/Src/system_stm32l4xx.c , the following exists:

/************************* Miscellaneous Configuration ************************/
/*!< Uncomment the following line if you need to relocate your vector Table in
     Internal SRAM. */
/* #define VECT_TAB_SRAM */
#define VECT_TAB_OFFSET  0x00 /*!< Vector Table base offset field.
                                   This value must be a multiple of 0x200. */
/******************************************************************************/
 
  /* Configure the Vector Table location add offset address ------------------*/
#ifdef VECT_TAB_SRAM
  SCB->VTOR = SRAM_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal SRAM */
#else
  SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH */
#endif

In my case, SCB->VTOR is being assigned the FLASH_BASE address of 0x08000000. However, the issue I am seeing occurs before SystemInit() is ever called in Startup/startup_stm32l4r9aiix.s within ResetHandler(). I am still patiently waiting for an STM FAE to get back to me since I sent them a CubeMX generated project in which they reproduced the issue and are investigating. As Tesla DeLorean pointed out, I hope it's not some anti-glitching mechanism that is being falsely activated when debugging.

Thanks

[waclawek.jan]

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

[SBEN .2]

Hello @Johannes​ ,

The debugger should neither encourage nor set the value of VTOR:

 

Best regards,

@SBEN .2​ 

[DerekR]

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.

[Johannes]

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)

[waclawek.jan]

> 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