STM32F407 Expected value for Option Byte "RDP": 0xAA, found: 0xFF

[Niobio]

Hi fellows,

I have a board with STM32F407ZGT6. But today the board stoped wihtout any reason, and when I open the STM32 Cube promgrammer using ST-Link V2, I can see the STM32407, the version, the size, so the chip is apparently fine, but I can't donload the firmware because the read out protection is active ( and I never changed the rdp to level 2), and when I go to option bytes and I try to change the value of the read out protection to AA, the software return the mensage: "Error: Expected value for Option Byte "RDP": 0xAA, found: 0xFF."

So I can't erase board, re-download the firmware... the board is dead.

Can anyone help me? I just need to erase the board and download the firmware again.

[Tesla DeLorean]

Sounds more like a connectivity issue.

Might suggest checking NRST is wired, and check Connect-Under Reset performance, and also BOOT0=HIGH, as means of stopping your own code running on the part.

You might want to try ST-LINK Utilities, and perhaps failing that use the System Loader (BOOT0=HIGH) via a USART connection and walk the device into a unprotect/mass-erase so you can recover access.

If you'd blocked JTAG/SWD access I doubt you'd have gotten this far.

[Niobio]

Hello @Community member​ , thx for the quicly answer

I tried with the BOOT0=HIGH using the st-link v2 without success, but when I using a UART communication with a CP2102 using the TX01 and RX01 pins, i have sucess in erase and download the firmware using the BOOT0=HIGH. But when i try again using the st-link v2 using STM32 ST-Link Utily returns the message that the RDP is active. Do you have any ideia what it might be?

[Tesla DeLorean]

Would tend to suggest an issue with the ST-LINK or the connectivity, double check signals and Grounds.

If a custom board might want to check voltages at VCAP pins, and capacitors placed.

[Uwe Bonnes]

Option Byte "RDP" = 0xff happens after option byte erase when not new options are set. RM0090 tells "Others: Level 1, read protection of memories (debug features limited)". Try other debuggers. They should be able to sett 0xaa, causing a chip erase.

[Niobio]

Hi @Uwe Bonnes​ 

Would you suggest me any other debugger that i can try?

[Javier1]

I am having the same issue with TWO nucleo- stm32f207ZG.

suddenly i launched a debugg session with stmCUbeIDE and the board was bricked, same as yours.

I suspect some noise from LEDs im working with could have corrupted the SW signal because it has been acting funky the whole morning.

12:26:20:796 : OPTION BYTE PROGRAMMING VERIFICATION:
 12:26:20:796 : Error: Expected value for Option Byte "RDP": 0xAA, found: 0xFF
 12:26:20:819 : Error: Option Byte Programming failed