2022-12-01 03:44 AM
I was happily debugging some code in my NUCLEO-F207ZG, the whole morning the debug sessions (stm32cubeIDE) have been quite glitchy.
Until the mcu somehow got briked and i cannot revive it.
I suspect noise in the SW lines comming from some external LEDs nearby had something to do with this issue, or power fluctuations when programming.
I am unable to Read the FLash content so i connected the board to the stCUBEProgrammer.
12:42:36:814 : STLinkUSBDriver.dll loaded
12:42:36:819 : STLinkUSBDriver.dll loaded
12:42:36:819 : ST-LINK SN : 066FFF323239524257191044
12:42:36:820 : ST-LINK FW : V2J39M27
12:42:36:821 : Board : NUCLEO-F207ZG
12:42:36:821 : Voltage : 3.24V
12:42:36:836 : SWD freq : 4000 KHz
12:42:36:837 : Connect mode: Under Reset
12:42:36:837 : Reset mode : Hardware reset
12:42:36:838 : Device ID : 0x411
12:42:36:850 : Revision ID : Rev 2.0
12:42:36:871 : flash loader C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin/FlashLoader/0x411.stldr is loaded
12:42:36:871 : STLinkUSBDriver.dll loaded
12:42:36:871 : ST-LINK SN : 066FFF323239524257191044
12:42:36:872 : ST-LINK FW : V2J39M27
12:42:36:872 : Board : NUCLEO-F207ZG
12:42:36:882 : Voltage : 3.24V
12:42:36:892 : SWD freq : 4000 KHz
12:42:36:892 : Connect mode: Under Reset
12:42:36:892 : Reset mode : Hardware reset
12:42:36:906 : Device ID : 0x411
12:42:36:910 : Revision ID : Rev 2.0
12:42:36:910 : Debug in Low Power mode is not supported for this device.
12:42:36:910 : Reading data...
12:42:36:910 : r ap 0 @0x1FFF7A22 0x00000004 bytes Data 0x0000201F
12:42:36:910 : failed to read the requested memory content
12:42:37:108 : UPLOADING OPTION BYTES DATA ...
12:42:37:109 : Bank : 0x00
12:42:37:109 : Address : 0x40023c14
12:42:37:109 : Size : 12 Bytes
12:42:37:109 : Reading data...
12:42:37:109 : r ap 0 @0x40023C14 0x0000000C bytes Data 0x0FFFFFED
12:42:37:110 : UPLOADING OPTION BYTES DATA ...
12:42:37:110 : Bank : 0x00
12:42:37:110 : Address : 0x40023c14
12:42:37:110 : Size : 12 Bytes
12:42:37:110 : Reading data...
12:42:37:110 : r ap 0 @0x40023C14 0x0000000C bytes Data 0x0FFFFFED
12:42:37:111 : UPLOADING ...
12:42:37:111 : Size : 1024 Bytes
12:42:37:111 : Address : 0x8000000
12:42:37:111 : Read progress:
12:42:37:111 : Reading data...
12:42:37:111 : r ap 0 @0x08000000 0x00000400 bytes Data 0x201F6411
12:42:37:111 : Error: Data read failed
What ****** me off is the OB->RDP suddenly shows as FF (read protection), im unable to change it back to AA (no read protection).
12:42:58:775 : UPLOADING OPTION BYTES DATA ...
12:42:58:775 : Bank : 0x00
12:42:58:775 : Address : 0x40023c14
12:42:58:775 : Size : 12 Bytes
12:42:58:776 : Reading data...
12:42:58:776 : r ap 0 @0x40023C14 0x0000000C bytes Data 0x0FFFFFED
12:43:02:844 : Option byte command : -ob RDP=170
12:43:02:847 : PROGRAMMING OPTION BYTES AREA ...
12:43:02:848 : Bank : 0x00
12:43:02:849 : Address : 0x40023c14
12:43:02:849 : Size : 12 Bytes
12:43:02:849 : OB buffer: edaaff0fc000001300000000
12:43:02:849 : Buffer program...
12:43:02:854 : halt ap 0
12:43:02:854 : w ap 0 reg 15 PC (0x20000000)
12:43:02:855 : w ap 0 reg 17 MSP (0x20000500)
12:43:02:856 : w ap 0 reg 16 xPSR (0x01000000)
12:43:02:858 : w ap 0 @0x20000D80 0x00000200 bytes Data 0x00000000
12:43:02:858 : w ap 0 @0x20000000 0x00000004 bytes Data 0x0000BE00
12:43:02:877 : w ap 0 @0x20000004 0x00000940 bytes Data 0xF000B580
12:43:02:877 : w ap 0 @0x20000D80 0x0000000C bytes Data 0x0FFFAAED
12:43:02:877 : Loader write option bytes...
12:43:02:877 : Init flashloader...
12:43:02:877 : halt ap 0
12:43:02:878 : w ap 0 reg 0 R0 0x00000001
12:43:02:878 : w ap 0 reg 1 R1 0x00000000
12:43:02:878 : w ap 0 reg 2 R2 0x00000000
12:43:02:878 : w ap 0 reg 3 R3 0x00000000
12:43:02:878 : w ap 0 reg 4 R4 0x00000000
12:43:02:878 : w ap 0 reg 5 R5 0x00000000
12:43:02:880 : w ap 0 reg 6 R6 0x00000000
12:43:02:881 : w ap 0 reg 7 R7 0x00000000
12:43:02:883 : w ap 0 reg 8 R8 0x00000000
12:43:02:884 : w ap 0 reg 9 R9 0x00000000
12:43:02:884 : w ap 0 reg 10 R10 0x00000000
12:43:02:885 : w ap 0 reg 11 R11 0x00000000
12:43:02:885 : w ap 0 reg 12 R12 0x00000000
12:43:02:888 : w ap 0 reg 13 SP 0x00000000
12:43:02:888 : w ap 0 reg 14 LR 0x20000001
12:43:02:889 : w ap 0 reg 15 PC 0x20000005
12:43:02:889 : w ap 0 reg 16 xPSR 0x01000000
12:43:02:890 : w ap 0 reg 17 MSP 0x20000D40
12:43:02:890 : w ap 0 reg 18 PSP 0x00000000
12:43:02:891 : run ap 0
12:43:02:894 : halt ap 0
12:43:02:895 : r ap 0 reg 0 R0 0x00000001
12:43:02:896 : w ap 0 reg 0 R0 0x40023C14
12:43:02:897 : w ap 0 reg 1 R1 0x0000000C
12:43:02:900 : w ap 0 reg 2 R2 0x20000D80
12:43:02:900 : w ap 0 reg 3 R3 0x00000002
12:43:02:901 : w ap 0 reg 4 R4 0x00000000
12:43:02:902 : w ap 0 reg 5 R5 0x00000000
12:43:02:904 : w ap 0 reg 6 R6 0x00000000
12:43:02:906 : w ap 0 reg 7 R7 0x00000000
12:43:02:907 : w ap 0 reg 8 R8 0x00000000
12:43:02:912 : w ap 0 reg 9 R9 0x00000000
12:43:02:913 : w ap 0 reg 10 R10 0x00000000
12:43:02:914 : w ap 0 reg 11 R11 0x00000000
12:43:02:914 : w ap 0 reg 12 R12 0x00000000
12:43:02:914 : w ap 0 reg 13 SP 0x00000000
12:43:02:915 : w ap 0 reg 14 LR 0x20000001
12:43:02:916 : w ap 0 reg 15 PC 0x200000DF
12:43:02:917 : w ap 0 reg 16 xPSR 0x01000000
12:43:02:917 : w ap 0 reg 17 MSP 0x20000D40
12:43:02:918 : w ap 0 reg 18 PSP 0x00000000
12:43:02:918 : run ap 0
12:43:06:294 : UPLOADING OPTION BYTES DATA ...
12:43:06:295 : Bank : 0x00
12:43:06:295 : Address : 0x40023c14
12:43:06:295 : Size : 12 Bytes
12:43:06:295 : Reading data...
12:43:06:297 : r ap 0 @0x40023C14 0x0000000C bytes Data 0x0FFFFFED
12:43:06:297 : OPTION BYTE PROGRAMMING VERIFICATION:
12:43:06:297 : Error: Expected value for Option Byte "RDP": 0xAA, found: 0xFF
12:43:06:317 : Error: Option Byte Programming failed
12:43:06:348 : Time elapsed during option Bytes configuration: 00:00:03.449
12:43:06:412 : UPLOADING OPTION BYTES DATA ...
12:43:06:412 : Bank : 0x00
12:43:06:412 : Address : 0x40023c14
12:43:06:412 : Size : 12 Bytes
12:43:06:413 : Reading data...
12:43:06:413 : r ap 0 @0x40023C14 0x0000000C bytes Data 0x0FFFFFED
Maybe i killed the flash somehow?
I tested with different nucleo boards and everything seems alright with CUBEProgrammer and CUBEide
Solved! Go to Solution.
2022-12-01 10:13 AM
What's your code doing to get the boards/chips in this state?
Does behaviour change if BOOT0 is strapped to VDD? There's a jumperable spot on the side of CN11
2022-12-01 10:59 AM
TBH getting 0xFF is more indicative of it being unable to communicate.
Connecting under reset, or holding in reset might be a way to wrestle control.
User code doing dumb things, like reconfiguring the pins, turning off the power, or saturating the system with IRQ or DMA activity, forcing the debugger to contend, can cause issues.
Strapping BOOT0 to VDD is one of the best ways to stop user code taking control, the ROM system loader is a relatively safe-harbour from which to gain and retain control of the system in a predictable state.
The tools are all very fragile, and don't report or handle error conditions well, but I've been railing on this for a decade plus..
2022-12-02 12:06 AM
>>TBH getting 0xFF is more indicative of it being unable to communicate.
I am going to explore this, it could be caused by a broken mcu?
>>Connecting under reset, or holding in reset might be a way to wrestle control.
I use cubeProgrammer with the "conection under reset" mode by default, doesnt work that way.
Tried connecting while releasing the reset button from the nucleo board, no luck either.
>>User code doing dumb things, like reconfiguring the pins, turning off the power, or saturating the system with IRQ or DMA activity, forcing the debugger to contend, can cause issues.
There is DMA activity for sure , but didnt give me any issue untill now, i suspect the problem begins when i connect the nucleo board to a new test rig i am developing....
>>Strapping BOOT0 to VDD is one of the best ways to stop user code taking control, the ROM system loader is a relatively safe-harbour from which to gain and retain control of the system in a predictable state.
Okay trying this
2022-12-02 12:09 AM
Thanks @Community member ..
>>What's your code doing to get the boards/chips in this state?
In dont think code its the issue here, there is some DMA activity with the ADCs but 1ms spaced.
The boards get in this state when i connect them to a test rig im developing for other boards.
I suspect the test rig is killing the nucleos.
>>Does behaviour change if BOOT0 is strapped to VDD? There's a jumperable spot on the side of CN11
Going to try this
Edit: I soldered a wire from BOOT0 to 3v3, then i connected the USB, i get the same results as before.
How do i know the mcu is in ROM system bootloader? i connected an USB cable to the USB OTG port and cubeProgrammer couldnt detect any DFU port.
2022-12-02 09:35 AM
If you use debug functionality, I think Cube Programmer has this, you should be able to see it with the PC in the 0x1FFF0000 type address range.
>>I am going to explore this, it could be caused by a broken mcu?
I suppose, but several aspects seem to be otherwise functional. You might want to submit this as an Online Support Request thing, see if the FAE have any insight or info off the large issue FAQ they consult.
2022-12-12 01:59 AM
>>If you use debug functionality, I think Cube Programmer has this, you should be able to see it with the PC in the 0x1FFF0000 type address range.
Already tried that, doesnt work.
>>You might want to submit this as an Online Support Request thing, see if the FAE have any insight or info off the large issue FAQ they consult.
I guess its worth to give it a shot.
After some hardware debugging there is a chance 12v spikes are getting trough GPIO protections.
This would kill only the GPIO fets and leave the MCU running deaf blind and mute.
2024-05-25 12:13 AM
Did you find anything out about this issue? I'm having the exact same issue with my stm32F401