2023-01-04 01:33 AM
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:
Dummy firmware:
Real firmware:
Any ideas? Thanks
2023-01-04 07:27 AM
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:
Will it work or not? Will it matter which reset strategy you use in the debug config?
Another test scenario:
2023-01-04 09:33 PM
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...
2023-01-04 11:00 PM
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?
2023-01-05 02:18 AM
Yeah maybe circuit related - if I comment out other code and leave the terminal code in, it also works, just not at the same time.
2023-01-05 02:19 AM
Hello @MSatt.4
Could you please run again the second scenario described by @mattias norlander ; but this time use the CubeProgrammer CLI not the GUI.
Kind regards,
Semer.
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2023-01-05 02:47 AM
C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin>STM32_Programmer_CLI.exe -c port=SWD mode=UR -d "C:\Users\malsattima\Development\firmware\Debug\firmware.elf" -v
-------------------------------------------------------------------
STM32CubeProgrammer v2.12.0
-------------------------------------------------------------------
ST-LINK SN : 53FF71065056705455430281
ST-LINK FW : V2J40S7
Board : --
Voltage : 2.75V
SWD freq : 4000 KHz
Connect mode: Under Reset
Reset mode : Hardware reset
Device ID : 0x495
Revision ID : Rev Y
Device name : STM32WB5x/35xx
Flash size : 1 MBytes
Device type : MCU
Device CPU : Cortex-M4
BL Version : 0xD5
Debug in Low Power mode enabled
Memory Programming ...
Opening and parsing file: firmware.elf
File : firmware.elf
Size : 202.00 KB
Address : 0x08000000
Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 50]
Download in Progress:
██████████████████████████████████████████████████ 100%
File download complete
Time elapsed during download operation: 00:00:04.977
Verifying ...
Read progress:
██████████████████████████████████████████████████ 100%
Download verified successfully
C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin>STM32_Programmer_CLI.exe -c port=SWD mode=UR -r32 0x1FFF8000 0x40
-------------------------------------------------------------------
STM32CubeProgrammer v2.12.0
-------------------------------------------------------------------
ST-LINK SN : 53FF71065056705455430281
ST-LINK FW : V2J40S7
Board : --
Voltage : 2.75V
SWD freq : 4000 KHz
Connect mode: Under Reset
Reset mode : Hardware reset
Device ID : 0x495
Revision ID : Rev Y
Device name : STM32WB5x/35xx
Flash size : 1 MBytes
Device type : MCU
Device CPU : Cortex-M4
BL Version : 0xD5
Debug in Low Power mode enabled
Reading 32-bit memory content
Size : 64 Bytes
Address: : 0x1FFF8000
0x1FFF8000 : 7FF9F1AA 80060E55 000001FF FFFFFE00
0x1FFF8010 : 00000000 FFFFFFFF 000000FF FFFFFF00
0x1FFF8020 : 000000FF FFFFFF00 000001FF FFFFFE00
0x1FFF8030 : 00000000 FFFFFFFF FFFFFFFF FFFFFFFF
C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin>STM32_Programmer_CLI.exe -c port=SWD mode=UR -run
-------------------------------------------------------------------
STM32CubeProgrammer v2.12.0
-------------------------------------------------------------------
ST-LINK SN : 53FF71065056705455430281
ST-LINK FW : V2J40S7
Board : --
Voltage : 2.75V
SWD freq : 4000 KHz
Connect mode: Under Reset
Reset mode : Hardware reset
Device ID : 0x495
Revision ID : Rev Y
Device name : STM32WB5x/35xx
Flash size : 1 MBytes
Device type : MCU
Device CPU : Cortex-M4
BL Version : 0xD5
Debug in Low Power mode enabled
Core run
C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin>
Not sure if that's the command line you were wanting, but it seems to work fine anyway, firmware works and OB's not erased. Performed multiple times without error.
2023-01-05 02:52 AM
Additionally, sometimes the IDE after flashing doesn't even get to the debugging stage, instead giving "Target unknown error 19" and the device is totally locked up (have to do FUS safe boot to restore).