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

[waclawek.jan]

That's the consequence of starting into bootloader - it's the bootloader, not the debuigger, which sets VTOR to the bootloader area.

JW

[Johannes]

In my design, I have a problem, that the debugger correctly stops at "void main()" and then gets lost when initializing "HAL_Init()". I use Timer 7 for system-TIC. I observe that the software gets lost as soon as the HAL initializes Timer 7 interrupt and then jumps into the bootloader

To clarify

I can see, that my program stops correctly at void main(), but VTOR points to 0x1FFF0000. Why is that? who sets VTOR at debug start? I assume, that the SWD / JTAG debugger will set some processor registers upon debug start. How would my software get to "void main()" but VTOR still pointing to bootloader?

I think, there is something wrong during debugger start. Maybe the debugger has modified the Programm counter correctly to reset vector (my program) but setting VTOR to zero failed somehow.

I never dealt with debug start. Is there some script running during debug start? Does anyone know where to look?

[Johannes]

Another strange observation:

When the debugger starts correctly, the flash-memory is mapped to 0x00000 (correctly)

If the debugger is not about to start correctly, the flash memory is NOT visible at 0x00000. But the register "SYSCFG / MEMRMP" (memory-remap) is zero, which means, that the flash should be visible at 0x000000

This is flash content. This is the vector table. First Stack-Pointer, Second: Reset-Vector

 

This is the memory content at 0, should have been exactly the same as 0x08000000. but it isn't. Reset Vector points to 0x1FFF51F5 (obviously bootloader code)

 

But Memory-Remap-Register shows zero. Flash should be remapped to zero.

Reference manual says:

After reset these bits take the value selected by boot0 pin (or option bit depending on nSWBOOT0 optiin bit) and BOOT1 option bit.

So I assume: If this register shows 0, the boot0-pin and the option bits are scanned correctly, and the flash memory should be at address 0

But it does only every second debug attempt.

[Johannes]

By the way: Playing with this setting does not do anything.

[waclawek.jan]

Which STM32?

Are any of the AN2606 conditions to enter bootloader for that chip, fulfilled? How is the BOOT0 pin connected?

JW

[DerekR]

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.

[Tesla DeLorean]

Based on other comments/threads STM32L4R7VIT6

Looking like BOOT0 is left floating, and not pulled LOW

In either case the L4 is running from the ROM, and the code there is setting the VTOR to 0x1FFF0000, not the debugger.

The default is actually ZERO

Typically the loader/application explicitly set SCB->VTOR in their respective SystemInit() function they call from their startup.s code for Reset_Handler

Most debuggers of any merit can run "debugger scripts", look up the respective documentation, and search the interwebs for actual examples.

[Tesla DeLorean]

>>But it does only every second debug attempt.

The fail-over behaviour is that the ROM is entered if the FLASH looks to be blank, ie 0xFFFFFFFF, perhaps your download/debug sequence is erasing and resetting the processor, causing it to fall back to doing this.

[DerekR]

Edit: Nope, never mind. Just encountered the issue again. CubeIDE 1.6.1 didn't make a difference.

[DerekR]

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.