Skip to main content
MSatt.4
MSatt.4
Associate II
Jan 4, 2023 9:33 AM UTC
Question

STM32WB55CG option bytes getting erased when debugging through STM32CubeIDE

Some strange behavior is happening when debugging our firmware through STM32CubeIDE, where it erases the option bytes upon flashing the firmware (0xFF @ 0x1FFF8000 onwards). The debugging session still launches ok and the firmware appears to be flashed correctly and working as intended.

This is especially annoying as it triggers the flash option bytes protection where it secures the memory and I have to manually restore it using the FUS safe boot mechanism. Our firmware is designed to go to shutdown mode each time which triggers this, so I can't do any work on it right now.

At first I thought it was a problem inside the firmware, but if I flash the ELF / srec artifact through the STM32CubeProgrammer directly, the problem goes away??

This never used to happen - took a break over the new year and I've come back to this problem.

Tried:

  • Creating a dummy firmware with size larger than ours (thinking its a size problem) - dummy firmware works fine, no erasing of OBs.
  • Dummy firmware is just a blinking LED, with a lot of padding (~280 KB), real firmware size around 200 KB
  • Adjusting optimization settings
  • Recreating the debug launch settings
  • Adjusting linker script with various offsets
  • The OPTKEY values required to unlock the flash aren't even in our firmware... checked with a binary dump. It's very unlikely our firmware is doing this
  • Stopping on the very first instruction and inspecting memory - the OB's are erased even here!

Dummy firmware:

0693W00000Y7NMUQA3.png 

Real firmware:

0693W00000Y7NMyQAN.pngAny ideas? Thanks

This topic has been closed for replies.

7 replies

mattias norlander
mattias norlander
ST Technical Moderator
Jan 4, 2023 3:27 PM UTC

Did you make any change to the debug configuration?

Do you version control the .launch-file? Can you check out a previous version or diff it to see if there is any change vs before your holiday when this worked?

What if you do this scenario:

  1. Let CubeProg stand-alone download your binary
  2. Create a new debug config which does not download the elf/srec file but only connect to and reset the target

Will it work or not? Will it matter which reset strategy you use in the debug config?

Another test scenario:

  1. Let CubeProg stand-alone download your binary
  2. After the download use the CPU GUI in CubeProg to step / run your code and then examine the OBs, did that also mess up the OBs?

In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question.
MSatt.4
MSatt.4Author
Associate II
Jan 5, 2023 5:33 AM UTC

Reverted back to the launch config I had before, but no difference (only unticked resume and stop on main). The frequency is set to auto on both configs too.

Tried different reset types with no difference.

For first scenario, letting CubeProg download program and not IDE, this works - I can terminate and restart debugging as much as I like, no OB's erased.

For second scenario, letting CubeProg download and run, this also works - I can step through, reset (all types), run and it all works fine, no OB's erased.

There were some code changes in our FW since I last debugged it in the CubeIDE, but I don't get why CubeProg works if it was that...

MSatt.4
MSatt.4Author
Associate II
Jan 5, 2023 7:00 AM UTC

There is a specific line of code that if I comment out the debugging works correctly, but it's relating to a terminal, nothing to do with flash memory / OB's.

Again, the exact same firmware built works if I flash it through CubeProg, so I'm still not sure what's happening - maybe circuit / voltage related?

Terms & ConditionsAccessibility statement