Nucleo-L433RC-P: Debug fails on first attempt but works on second

[freeflyer]

I am developing software on the Nucleo-L433RC-P board but have a strange situation when debugging.

The first time I debug, the software does not run and I get the following error...

Break at address "0x1fff2ce8" with no debug information available, or outside of program code.

Break at address "0x1fff2cd6" with no debug information available, or outside of program code.

As shown in the screenshot below...

However, the second time I debug it works correctly.

Why does it not work correctly on the first debug, but then works correctly on the second debug ?

I have tried two different boards (one of which is brand new and never been used) but the behaviour is the same, so it must be a software issue.

[Tesla DeLorean]

That's from the ROM, so either the BOOT0 is HIGH, or the FLASH is blank and doesn't contain viable vector table, so goes to ROM code instead.

[freeflyer]

BOOT0 is pulled low via a 10k resistor on this board and the pin on the header is floating

why would the flash be blank when I debug ?

[Tesla DeLorean]

Well, depends on the sequencing, but if you erase, and reset, this determination may be sticky and require a power-cycle to clear on some STM32 parts. Relates to how it latches option bytes, and protects against code recovery attacks.

You'd want to look at the connection options chosen in the programmer.

The debugger might be resetting to gain control of the part, or to get a clear start.

The key take-away is that it's running code from ROM rather than FLASH, and has no source code to associate to that.

You could perhaps try a different debugger, or check firmware version in ST-LINK

[freeflyer]

I've tried "Software system reset" and "Connect under reset" options, but it made no difference.

One of the boards I tested was brand new (never been used).

The only thing I can think of is that my software uses the blue top button for shutdown and wakeup (using SYS_WKUP2).  Could this be a problem ?

[freeflyer]

When I plugged the new board in the firmware for the stlink did an update to the latest version

I just click the debug button.In STM32CubeIDE, I don’t manually erase

Could it be a bug in the stlink firmware?

This problem occurs on two different boards and one is brand new

[Tesla DeLorean]

Not sure if it matters if the boards are new, or not

https://www.st.com/resource/en/reference_manual/rm0394-stm32l41xxx42xxx43xxx44xxx45xxx46xxx-advanced-armbased-32bit-mcus-stmicroelectronics.pdf#page=78

There are boot setting in the Option Bytes, and it checks for 0xFFFFFFFF patterns in the vector table.

Does your code work reliably out of a power cycle? That's the primary thing to worry about.

When the debugger is erasing, resetting and break-pointing it could well trigger annoying behaviours in the part and it's protection methods. Not sure I'd spend too much time fighting these shadows. You could make a boot loader that gates access to an application firmware you develop deeper into the FLASH, and then the block/sector at 0x08000000 wouldn't need to get erased in your crash-n-burn debug cycle.