How Do STM32 RDP and WRP Option Bytes Protect Flash Memory?

Detailed Explanation

Every STM32 has a small, separately-erasable block of non-volatile configuration called option bytes, distinct from the main user flash array. Option bytes control boot behaviour, brown-out reset thresholds, watchdog defaults — and two protection mechanisms that matter for any product shipping firmware that has commercial or security value: RDP (Readout Protection) and WRP (Write Protection).

These two mechanisms are independent and solve different problems:

• RDP controls whether flash contents can be read back out through the debug port or the ROM bootloader.
• WRP controls whether specific flash sectors can be erased or written, regardless of RDP level.

A product can use either, both, or neither, depending on what it's actually protecting against.

RDP: Readout Protection Levels

RDP has three levels, configured via a single option byte. The exact byte values differ slightly by STM32 family (check the Flash chapter of your part's reference manual — RMxxxx), but the three-level model is consistent across the whole STM32 range:

Level 1 is the level most products should use in the field. It stops a debug probe from being connected to a shipped unit and having its firmware read straight off flash — the most common and lowest-effort form of IP theft or firmware cloning. Because downgrading from Level 1 back to Level 0 forces a mass erase, an attacker who lowers protection to regain debug access also destroys the firmware they were trying to read — there's no way to have both.

Level 2 removes debug access permanently, including your own. Once set, no debug probe, bootloader read command, or ST factory process can ever re-enable the debug port on that specific chip. This is appropriate when firmware IP value or safety/security requirements genuinely justify losing the ability to debug a unit again — but it also means every field-return, in-field diagnostic, and firmware-recovery path must be fully designed around never touching SWD/JTAG again. Most products are well served by Level 1; Level 2 is a deliberate, harder-to-reverse decision that should follow a specific threat model, not be applied as a default "more security is always better" setting.

WRP: Write Protection

WRP operates independently of RDP and protects specific flash sectors (or pages, depending on family) from being erased or written — including by the application itself, the bootloader, or a debug probe (if RDP still permits debug access). It does not prevent reading a protected sector; that's RDP's job.

The most common use of WRP is protecting a bootloader region from being accidentally or maliciously overwritten by the application firmware or a faulty OTA update. If the first-stage bootloader can be corrupted by a bug in the application update logic, a device can be bricked with no recovery path other than a debug probe (or none, if RDP Level 2 is also set). Write-protecting the bootloader sector means even a firmware bug that mis-calculates a flash-erase address cannot destroy the one piece of code capable of recovering the device.

WRP is set per-sector (or per-page-range) via option bytes, using the same STM32CubeProgrammer or ST-Link-based tooling used for RDP.

How Option Bytes Are Written

Option bytes are programmed through STM32CubeProgrammer (GUI or CLI), the ST-Link Utility on older toolchains, or programmatically via the flash option-byte registers from application firmware (with appropriate unlock sequences — most families require writing specific unlock keys to an OPTKEYR register before option bytes become writable). A change to option bytes only takes effect after an option-byte reload, which is typically triggered by an OBL_LAUNCH bit or a system reset, depending on family.

Because setting RDP Level 2 is irreversible, production provisioning scripts that set option bytes should be treated with the same care as any one-way, non-reversible manufacturing step — tested extensively on scrap units before being used on a production line, with an explicit sign-off step before Level 2 is ever applied outside a test environment.

Design Considerations

• Never set RDP Level 2 on a development or evaluation board. A Nucleo or Discovery board with RDP Level 2 set has permanently lost its ST-Link debug capability — the on-board debug probe can no longer program or halt the target MCU. This is a common and completely avoidable way to lose a development board.
• Level 1 is sufficient for most commercial products. It blocks the casual firmware-extraction path (attaching a debug probe to a shipped unit) while preserving the ability to recover a bricked field unit through a proper repair/RMA process using specialist ST tooling.
• Combine WRP with a bootloader, not instead of RDP. WRP stops accidental or buggy self-erasure of a critical region; it does not stop someone with debug access from simply reading that region's contents. If confidentiality matters, RDP is the mechanism that matters — WRP is about integrity, not confidentiality.
• Plan the field-recovery path before choosing Level 2. If a device bricks in the field (corrupted firmware, failed OTA), Level 1 with a working bootloader or DFU recovery path lets you recover it. Level 2 means the only recovery path is whatever your own application firmware can do for itself — typically a robust OTA update scheme with a fail-safe dual-image or golden-image fallback, because there is no external rescue option left.
• Option-byte provisioning is a production step, not a firmware feature. Treat it the same way as any irreversible manufacturing operation — validated on test units, gated behind an explicit step in the production flow, and never bundled silently inside a firmware image that could be flashed to the wrong batch of boards.

Common Mistakes

Setting RDP Level 2 during development and losing debug access to a dev board

This is the single most common RDP mistake. STM32CubeProgrammer will normally warn before setting Level 2, but scripts or CI flashing pipelines that set option bytes programmatically without human confirmation have bricked debug access on development hardware. Keep RDP Level 2 provisioning entirely separate from any script or firmware image used during development.

Expecting RDP to stop firmware from being extracted over a communication interface

RDP only blocks the debug port and ROM bootloader read path — it has no visibility into what the running application chooses to send over UART, BLE, or any other peripheral. A firmware image that includes a debug command allowing arbitrary memory reads over a serial console defeats RDP entirely, regardless of the level set. Firmware-level command interfaces need their own access control, independent of RDP.

Assuming WRP protects against reading a sector's contents

WRP is a write/erase protection mechanism only. A sector protected by WRP can still be read freely by anyone with debug access (unless RDP also restricts reads). Products that need both integrity and confidentiality protection for a region — for example, a secure bootloader holding key material — need RDP Level 1 or 2 and WRP together, not one or the other.

Forgetting that a Level 1 → Level 0 downgrade mass-erases flash

A downgrade from RDP Level 1 back to Level 0 is a normal, supported operation — but it triggers a full mass erase of user flash as a security measure, so the firmware is gone afterward. Production or repair processes that need to re-flash a Level 1 unit should plan for this: downgrading and re-flashing is a two-step process (erase, then program), not a simple debug-and-continue.

If you're building a product where firmware confidentiality, secure boot, or field-recovery design genuinely matters, Zeus Design's firmware development service designs STM32 flash-protection and provisioning strategies — including the production tooling to apply them safely — as part of a complete embedded firmware engagement.