Let’s break down your RDP level issue—elevating to Level 1 works as expected, but downgrading to Level 0 leaves you stuck with no debugger connection and a non-running program, even after power cycling. This is a typical pain point with STM32’s read protection, so let’s start with code checks and then move to hardware/debugger fixes.

First, Verify Your RDP Downgrade Code Flow #

STM32H7 requires a strict sequence to modify RDP options, especially when downgrading (since Level 1 → Level 0 forces a full chip erase by hardware). Here’s what to audit in your code:

1. Did you properly unlock FLASH and Option Bytes? #

You must unlock both the main FLASH controller and the option bytes before modifying RDP settings. Skipping either will silently fail the operation:

// Unlock main FLASH
if (HAL_FLASH_Unlock() != HAL_OK) {
  Error_Handler();
}
// Unlock Option Bytes
if (HAL_FLASH_OB_Unlock() != HAL_OK) {
  Error_Handler();
}

2. Are you setting the correct RDP Level value? #

Double-check the RDPLevel parameter in your FLASH_OBProgramInitTypeDef config. For STM32H7:

• RDP Level 0 = OB_RDP_LEVEL_0 (underlying value 0xAA)
• RDP Level 1 = OB_RDP_LEVEL_1 (underlying value 0xBB)
  If you accidentally set an invalid value, the option bytes could become corrupted, leaving the chip in an unresponsive state.

3. Did you wait for the Option Byte programming to complete? #

After calling HAL_FLASHEx_OBProgram(), ensure you don’t trigger a reset immediately until the operation finishes. While the HAL function is blocking, if you’re using a custom implementation, you’ll need to poll the FLASH_SR_BSY bit to confirm the operation is done:

FLASH_OBProgramInitTypeDef ob_cfg = {0};
HAL_FLASHEx_OBGetConfig(&ob_cfg);
ob_cfg.RDPLevel = OB_RDP_LEVEL_0;

// Program the option bytes (this triggers full chip erase automatically)
if (HAL_FLASHEx_OBProgram(&ob_cfg) != HAL_OK) {
  Error_Handler();
}

// Re-lock Option Bytes and FLASH
HAL_FLASH_OB_Lock();
HAL_FLASH_Lock();

// Trigger a proper system reset (don't just power off)
NVIC_SystemReset();

4. Did you disable interrupts during the operation? #

Interrupts firing mid-option-byte programming can corrupt the process. Wrap your RDP code in a critical section:

__disable_irq();
// ... your RDP modification code ...
__enable_irq();

Fixing the Debugger Connection Issue #

If your code checks out, the problem is likely with how your debugger is connecting to the post-erase chip:

• Enable "Connect under reset" in STM32CubeIDE: Open your debug configuration → Go to the "Debugger" tab → Check the "Connect under reset" box. This forces the debugger to connect before the chip boots, bypassing any startup issues from the erased flash.
• Use ST-Link Utility to force an erase: If CubeIDE still can’t connect, open ST-Link Utility, go to Target > Connect (if it fails, try Target > Connect Under Reset), then run Target > Erase Chip. This will wipe any residual option byte issues and restore connectivity.
• Update your Nucleo’s ST-Link firmware: Outdated ST-Link firmware can struggle with RDP state changes. Use STM32CubeIDE’s built-in ST-Link Upgrade tool (under Help > ST-Link Upgrade) to flash the latest firmware.

Final Notes #

If you’ve followed all these steps and still have issues, it’s possible the option bytes were permanently corrupted (though rare with proper code). In that case, you may need to use the STM32 System Bootloader (via UART/USB) to reflash the chip.

内容的提问来源于stack exchange，提问作者Guillaume Petitjean