Could not disable RDP at STM32WB55CEUX chip in my custom board

qpdkvn · ‎2019-09-19

I had a problem while uploading firmware into my custom board.

I used ST-Link attached at NUCLEO-F091RC board, and I could read Option Bytes and Memory at 0x00000000 using ST-Link Utility and STM32CubeProgrammer.

But I can't read or erase flash memory.

It notifies "Can not read memory! Disable Read Out Protection and retry."

and when I try to change Option bytes, notifies "Could not set Option bytes! Please reset the target and retry."

and this is the log when I tried to download and debug with STM32CubeIDE.

STMicroelectronics ST-LINK GDB server. Version 5.2.3

Starting server with the following options:

Persistent Mode : Disabled

Logging Level : 1

Listen Port Number : 61234

Status Refresh Delay : 15s

Verbose Mode : Disabled

SWD Debug : Enabled

Waiting for debugger connection...

Debugger connected

-------------------------------------------------------------------

STM32CubeProgrammer v2.1.0

-------------------------------------------------------------------

Log output file: C:\Users\ADMINI~1\AppData\Local\Temp\STM32CubeProgrammer_a17080.log

ST-LINK SN : 066AFF545753845187161939

ST-LINK FW : V2J33M25

Voltage : 0.00V

SWD freq : 4000 KHz

Connect mode: Under Reset

Reset mode : Hardware reset

Device ID : 0x495

Device name : STM32WBxx

Flash size : 512 KBytes

Device type : MCU

Device CPU : Cortex-M0+/M4

Memory Programming ...

Opening and parsing file: ST-LINK_GDB_server_a17080.srec

File : ST-LINK_GDB_server_a17080.srec

Size : 10288 Bytes

Address : 0x08008000

Erasing memory corresponding to segment 0:

Erasing internal memory sectors [8 10]

Error: failed to erase memory

Encountered Error when opening D:\Tools\STMicroelectronics\STM32CubeIDE_1.0.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_1.0.0.201904021149\tools\bin\STM32_Programmer_CLI.exe

Error in STM32CubeProgrammer

Target is not responding, retrying...

Error! Failed to read target status

Debugger connection lost.

Shutting down...

This is the default option bytes.

I think the problem is RDP isn't Level 0.

How can I upload firmware to my custom board or disable RDP?

Thank you.

Remi QUINTIN · ‎2019-10-09

I see something strange regarding the SFSA option byte. is it 0x00?

If it is, I am afraid the board became unusable. I would like to know what did you do to come to this situation where the complete flash memory is secure and so completely inaccessible.

Normally SFSA is only accessed by the CP2 core. It is only set to 0x00 when an illegal access is done to a secure area. This is one feature of the STM32WB. The goal is to protect the content of the flash in case of an illegal access.

akarp.2161 · ‎2021-03-11

Hi!

I got the same problem. In my program, there was a bootloader that erased / wrote sectors (of course, to the address of the beginning of the BLE Stack & FUS). After installing RDP level 1 (0xBB) and rebooting, the device stopped functioning. After resetting RDP to 0xAA, it is not possible to read or erase any sector. Also SFSA = 0x00. By the way, if you run "full chip erase" from CubeProgrammer, the chip will also be blocked ("SFSA = 0x00")?

Remi QUINTIN · ‎2021-03-12

What is your board? custom or ST board?

Is it your own bootloader?

Did you manage to upgrade the FUS to version 1.1.0? What is the current FUS version?

If not, I am afraid the board became unusable. You wont be able to program or erase the Flash memory anymore.

akarp.2161 · ‎2021-03-13

Custom board, custom bootloader.

When working with RDP 0xAA, everything was fine for a long time. Used STM32Cube_FW_WB_V1. 10.1. The FUS version in this package is 1.1.2, if I'm not mistaken. Now, operations to delete the CPU2 firmware or update the FUS also lead to erase/write errors. Now I need to figure out what I did wrong to avoid such irreversible problems in the future.

Remi QUINTIN · ‎2021-03-13

If you managed to upgrade the FUS to version V1.1.2, we can unlock your boards.

Connect to your board and write 0x00008000 at address 0x5800040C. This will reset your board to its default manufactory configuration and get the M0+ core ready to execute any secure command like FW delete and upgrade.

I assume that protecting the board via RDP = 0xBB (protection level = 1) and then trying to reset it to level 0 may have triggered this blocking situation. This is not expected but if you had an electrical spike at the same time, the embedded security may have considered this as a hack and blocked the whole system as a protective reaction.

azzurri · ‎2021-06-12

Hello @Remi QUINTIN , I have the same issue. The board seems blocked even if RDP is set to 0xAA. SFSA option byte is 0x00 as in @안 재우 's case.

I have tried to write 0x00008000 at address 0x5800040C but the operation is not working (photo attached). Is there any other possible solution?

Remi QUINTIN · ‎2021-06-13

I dont see any error in your log. Did you reset the board after this write access?

Could you download the option bytes ?

azzurri · ‎2021-06-14

Hi @Remi QUINTIN Thank you for your answer. Okay, I thought that I should read 0x00008000 after the write operation.

Yes, I can read the obtion bytes (photo attached).

Remi QUINTIN · ‎2021-06-14

Strange that the SBRV value remains pointing on the last sector of the Flash memory. I expected it to be pointing on the FUS at sector 0x3D000 with SFA = 0xF4.

Did you perform a full power cycle (powerr off/on)?