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.

[KnarfB]

I don't see any effect in your code lines 11-15 and would delete it. Would also avoid calling malloc/free for that at all. Can only imagine that you observe a stack overflow by a spurious interrupt or other kind of heap corruption.

Make sure that _Min_Heap_Size and _Min_Stack_Size have realistic values (in .ld file or STM32CubeMX) especially because the issue started to show up only when your code was growing. 

Maybe double-check stack usage by stack painting Measuring Stack Usage the Hard Way | Interrupt 

hth

KnarfB

[michaeljyti]

• It’s likely more of a dynamic memory allocation issue than the string library itself especially if you're not freeing memory or handling nullter minators properly.

• How exactly does it fail? A hard fault suggests memory corruption or access violation otherwise you might be stuck in a loop or overwrite.

• If you're not using the message output, consider simplifying with a custom strmalloc to avoid redundancy it's cleaner and more efficient.

[michaeljyti]

This issue often occurs due to incorrect or incomplete flash memory initialization during the first debug session. On the second attempt, the debugger properly loads and executes the code  try enabling Full chip erase before programming to ensure consistent behavior.

[michaeljyti]

This issue usually happens due to improper flash memory initialization during the first debug. Enable the "Full Chip Erase" option to ensure the code loads correctly every time.

[michaeljyti]

If BOOT0 is low and you're still seeing blank flash during the first debug, it could be that the debugger isnt properly loading the program on the first attempt. Try enabling Full Chip Erase and ensure your debug configuration includes program loading before starting execution.

[freeflyer]

It fails on line 168 of the 'w25qxx_init' function and then the debugger crashes.  When I pause the debugger it appears to go outside the flash area with the error "Break at address "0x1fff2d24" with no debug information available, or outside of program code."

I did not write the w25qxx driver, I got the driver from here...

https://github.com/mengguang/w25qxx

I do not understand what this line is doing anyway....

    char *version_buffer = malloc(strlen(W25QXX_VERSION) + 1);

Its strange how it also happens alternately

First debug flash and it fails, second debug flash and it works and so on....

[freeflyer]

Thanks all, how do I enable Full Chip Erase and ensure my debug configuration includes program loading before starting execution ?

I cant see any options for those in the debugger settings ?

[michaeljyti]

Issue seems related to uninitialized memory or undefined behavior in the function specifically the usage. Try checking heap setup in linker script and ensure memory is fully cleared before each debug session.

[michaeljyti]

Yes, this happens when flash isn't fully initialized in the first debug. Enabling "Full Chip Erase" before programming often fixes the issue and ensures stable execution every time.

[KnarfB]

allocate heap memory to hold a copy of W25QXX_VERSION and freeing that memory immediately afterwards. Don't see that in the github you mentioned. Probably only relics from some deleted debug output ...

hth

KnarfB