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

[DerekR]

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

[Amel NASRI]

Hi @DerekR​,

For sure, the flashloader patches will be available for all IDEs in the STM32CubeL4 package in its coming version.

-Amel

[MCU Support Center · Accepted solution]

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]

Hi @MCU Support Center​ ,

Thanks for filling in the details.

JW

[Tesla DeLorean]

Mark as best answer so we don't need to dig down three pages, thanks​

[Johannes]

Hm.. I replaced the provided files in this folder

C:\ST\STM32CubeIDE_1.5.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_1.6.0.202101291314\tools\bin\FlashLoader

and got this error message:

Error: failed to download the File

Encountered Error when opening C:\ST\STM32CubeIDE_1.5.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_1.6.0.202101291314\tools\bin\STM32_Programmer_CLI.exe

Error in STM32CubeProgrammer

Debugger connection lost.

Shutting down...

What did I miss?

Johannes

I am using CubeIDE Version: 1.6.1

Build: 9958_20210326_1446 (UTC)

on STM32L4R7 with Firmware Package

STM32CubeL4 Firmware Package V1.17.0 / 11-February-2021

[DerekR]

Hey @Johannes​ 

I haven't seen this issue. I compared the 0x470 and 0x471 CubeIDE flash loader files in the PEMPTY_Patches file above with those sent to me directly and they are the same, so I am not sure what your issue could be. I only replaced those files and both STM32CubeIDE and STM32CubeProgrammer work fine for me. I did upgrade to CubeIDE 1.6.1 a few weeks ago so everything else looks the same. Hopefully an STM employee can provide some insight for your error.

[Johannes]

Hello SBEN.2

you are right. The debugger should not set VTOR. This would not be a problem, if the debugger would set the memory configuration correctly.

Example:

I use

• CubeIDE 1.7.0
• Nucleo L4R5ZI
• STM32Cube MCU Package for STM32L4 Series V1.17.0
• STLinkV2 (part of the Nucleo board). Firmware V2J38M27

I generated the default project for nucleo L4R5ZI with "new project" from CubeIDE TargetBoardSelector and compiled it without and changes. (linked to Flash)

I started a debug session with a breakpoint directly on the reset-Handler.

"bl SystemInit" in startup_stm32l4r5zitx.s line 66

Pin PH3 (Boot) is wired with 10k to GND on Nucleo Board. The device should start from Flash. Flash-Memory (0x08000000) should be mirrored to address 0

Vector table should be at address 0 being the same as at 0x080000000

 

So I stopped with a breakpoint at "bl systemInit"

When looking at the disassembler window, this is at location 0x08000aac (flash memory). This is fine

 

When I open a memory window, I can see, that at address 0x0 there is a bootloader vector table

When reading the Register "VTOR", it says 0

 

so the vector table is still mapped to 0x0, but the flash memory is NOT mapped to 0x0

As soon, as I let the debugger run the code and the software engages any IRQ, the cpu will jump into the bootloader, because the vector table is not mapped to 0x0

possible workaround:

enable this line in code by defining a global "#define USER_VECT_TAB_ADDRESS"

Now the code sets the VTOR register to 0x0800 0000 pointing into flash code.

 

Question:

• Why does the debugger not set the memory mapping correctly? Why is flash not mapped to 0x00?

Obviously the debugger jumps to 0x08000000 upon debug start instead of mapping the memory correctly and jumping to 0x0 (reset vector)

Side effect: If you now press "reset" during debugging, The software jumps into bootloader instead of jumping into flash code

I think the debugger does not setup the target correctly on debug start.

[NArnd]

Possibly related to the issue reported here:

https://community.st.com/s/question/0D53W000013pTV9SAM/stm32l4r7zit-program-download-or-program-start-problem

[DM.7]

Hi,

When are these going to be released properly? I have wasted a week of development with this problem