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]

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

That means, you're already suspecting this is bootloader entry, and so do I.

Check for bad solder joints and shorts. Decrease the value of that resistor.

JW

[DerekR]

Hey JW,

Thanks for your reply! PH3-BOOT0 was my first suspicion but this project was originally created and running in Keil uVision IDE before being ported to CubeIDE a year ago. I don't recall seeing this issue in Keil before, but it may have just gone unnoticed or maybe Keil handled it differently.

Based on your response, are you stating that PH3-BOOT0 is still read to determine the application start address even when using the debugger in CubeIDE?

Edit:

Looking at the STM32L4R9I-DISCO devkit from which this project was based on, it appears PH3-BOOT0 is pulled to ground with a 100K ohm resistor.

 

Thanks,

Derek

[HBaga.1]

I'm also interested to know the solution to this as I'm having the same issue on my IOT Discovery board with STM32L4S5. The first debug always end up with the same issue as above, and the only way to recover is clicking the "restart debug session", or re-uploading the same code. Even pushing the "Reset" button on the Discovery does not fix it.

[Tesla DeLorean]

It can enter the boot loader if the image in flash is not valid. The option byte settings can take a power cycle to be acted upon.

[DerekR]

I did read in the MCU datasheet that if the application flash bank is erased that it will default to the system memory (bootloader) space. Since I am not changing the option bytes, and based on the responses so far, it could be one of the following:

1. PH3-B00T0 has a bad connection to ground.

2​. STM32CubeIDE or ST-Link is not properly programming the flash or is erasing the first page/sector after programming and verification completes.

"Verify" is enabled but I wonder if it's booting the application even if verification fails.​ Maybe I can find those details in the logs.

[DerekR]

Hey HBaga,

Are you also using a ST-Link? If so, is it a V2 or V3?

Thanks!​

[waclawek.jan]

What I meant with decreasing the resistor value is, that would there be some conductive debris around given pin/tracks (soldering residui for example), this would help. Resoldering the pin to exclude bad soldere joint, decreasing the resistor (even to zero if you don't use the pin otherwise) and cleaning the surroundings is a quick task and would never harm.

You don't jump into the bootloader deliberately anywhere in your program, do you?

This of course still can be also something else, e.g. software error ending up by coincidence in the bootloader area.

You should also review all possible bootloader entry methods as per AN2606, and if there's any chance to avoid some (e.g. by setting some of the option bits), try to use them.

JW

[HBaga.1]

The B-L4S5I-IOT01A Discovery kit comes with a STLINK V2-1 debugger/programmer.

[Johannes]

I have a similar problem. I found out, that the debugger obviously does not set the Vector Table correctly

I case of a non running debug session, I can halt the CPU and look at CPU register "VTOR", which stores the Vector table address.

Here: VTOR points to 0x1FFF0000

Now we need to know, how to encourage the debugger to set VTOR correctly every time. ...