Senior

Solved

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

Forum|Forum|5 years ago
June 9, 2021
24 replies
14724 views

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

This topic has been closed for replies.

Best answer by MCU Support Center

Hi All,

the reason of what you are seeing is due to the PEMPTY flag not being cleared properly by the flash loaders used by STM32CubeIDE/STM32CubeProgrammer, IAR or Keil when downloading the application and starting the debugger.

With the PEMPTY flag set, the STM32 boots from system memory instead of user memory (details at 3.7.5 in the RM0394 Rev 4)

These patches will be integrated within the IDEs ASAP:

Keil pack will be released soon.

IAR and STM32CubeIDE patchs will be integrated in the next IDEs release.

In the meantime, to solve the issue, you can use the attached files to replace the original flash loaders in the installation folders.

Best Regards

MCU support center

waclawek.jan

Super User

> 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

DerekRAuthor

Senior

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

Visitor II

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.

DerekRAuthor

Senior

Hey HBaga,

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

Thanks!

HBaga.1

Visitor II

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

Tesla DeLorean

Guru

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.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..

DerekRAuthor

Senior

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.

waclawek.jan

Super User

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

Johannes

Senior

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. ...

SBEN .2

Visitor II

Hello @Johannes ,

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

Best regards,

@SBEN .2

waclawek.jan

Super User

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

JW

Johannes

Senior

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

Senior

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.

Tesla DeLorean

Guru

>>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.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..

Johannes

Senior

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

waclawek.jan

Super User

Which STM32?

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

JW

Tesla DeLorean

Guru

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.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..

Show more replies

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded