STM32 Unlock: RDP Levels, Recovery and Hard Limits

Why STM32 Read-Out Protection Matters

STMicroelectronics ships hundreds of STM32 variants—from the low-cost STM32F0 to the high-performance STM32H7—and every one of them includes a hardware mechanism called Read-Out Protection (RDP). RDP is the primary gate between an attacker (or a legitimate recovery engineer) and the firmware stored in internal flash. Understanding how it works is the first step in any STM32 unlock discussion.

RDP is not unique to STM32. Other ARM Cortex-M vendors implement similar schemes; for example, GD32 devices differ from STM32 in subtle but important ways despite sharing the same core architecture. NXP, Renesas, and Infineon each have their own flavors. But STM32’s three-level system is among the most widely deployed, so it deserves a detailed treatment.

The Three RDP Levels Explained

STM32 microcontrollers define three protection states. The level is stored in the option bytes—a small, dedicated region of flash that the CPU reads at boot to configure security, watchdog behavior, and other hardware policies.

RDP Level 0 — No Protection

This is the factory default. Flash memory is fully accessible through the debug port (SWD or JTAG), the bootloader (UART, USB DFU, SPI, I²C depending on the part), and from user code. You can read, write, and erase flash freely. There is nothing to unlock.

RDP Level 1 — Read-Out Protection Active

When RDP is set to Level 1:

• The debug interface (SWD/JTAG) can still connect to the chip, but any attempt to read flash or SRAM returns a bus error.
• The built-in bootloader (system memory) is active, but read-back of flash through it is blocked.
• Code running from flash can still access flash normally—applications execute without issues.
• If you regress from Level 1 back to Level 0 (by rewriting the option bytes), the chip performs a mass erase of all user flash and SRAM before the debug port is reopened.

This mass-erase-on-regression is the central security guarantee. It means you can recover the chip for reuse, but you lose the firmware. The intent is clear: the silicon vendor gives you a way to reclaim hardware without giving you a way to steal code.

RDP Level 2 — Permanent Protection

Level 2 is irreversible. Once set:

• The debug port (SWD/JTAG) is permanently disabled at the hardware level. The JTAG/SWD pins become ordinary GPIO.
• The option bytes themselves are locked—you cannot write to them.
• The system bootloader is either disabled entirely or restricted (varies by series).
• There is no regression path. No software command, no ST-Link trick, no option-byte rewrite can bring the chip back to Level 1 or Level 0.

RDP Level 2 is the “point of no return.” It is designed for production devices where the manufacturer has decided that firmware confidentiality outweighs any future need for debug access.

How RDP Interacts With Other STM32 Security Features

RDP does not work in isolation. Modern STM32 families layer additional mechanisms on top of it:

For a broader view of how debug-port locking and TrustZone interact across vendors, see our coverage of ARM Cortex-M firmware readout techniques.

STM32 Unlock at RDP Level 1: The Standard Procedure

The most common STM32 unlock scenario is a chip stuck at RDP Level 1 where the owner has lost the source code or the original programmer and simply needs to reuse the hardware. The procedure is straightforward:

1. Connect an ST-Link or J-Link to the SWD pins (SWDIO, SWCLK, GND, and optionally nRST).
2. Open STM32CubeProgrammer (or the older ST-Link Utility).
3. Navigate to the Option Bytes panel.
4. Change the RDP level from 1 to 0.
5. Click Apply. The tool will warn you that a mass erase will occur.
6. After the erase completes, the chip restarts at RDP Level 0 with blank flash.

You can also do this through the STM32 system bootloader using UART or USB DFU with the -ob commands in STM32CubeProgrammer CLI. The result is the same: mass erase, then open access.

When Level 1 Unlock Fails

Occasionally the regression command does not work as expected. Common causes include:

• Damaged SWD pins. If SWDIO or SWCLK have been repurposed as GPIO and the firmware drives them hard at boot, the debugger cannot gain control. Holding nRST low while connecting, or using the “connect under reset” mode in CubeProgrammer, usually resolves this.
• Power supply issues. The option-byte write and mass erase draw current spikes. A weak bench supply or a long, thin wire can cause a brownout mid-erase, leaving the option bytes in a corrupted state.
• Misidentified part. Some clone or GD32 parts that mirror the STM32 architecture respond to the same SWD protocol but have different option-byte layouts. Using the wrong device profile in the programmer can corrupt the bytes rather than clear them.
• RDP is actually Level 2. The debugger may report “cannot read option bytes” or return all-zeros. If the debug port is truly dead, you may be looking at Level 2.

STM32 Unlock at RDP Level 2: Hard Limits

There is no documented software path to reverse RDP Level 2. The debug port is fused off at the hardware level. This is by design and is the reason STMicroelectronics offers the level in the first place—it provides an assurance to product manufacturers that their firmware cannot be extracted through normal means.

What About Fault Injection and Side-Channel Attacks?

Academic and commercial security labs have demonstrated attacks against specific STM32 families:

• Voltage glitching: By precisely timed voltage drops on VDD during the boot sequence, researchers have been able to skip the RDP check on certain STM32F0 and STM32F1 parts, causing the chip to boot as if it were at Level 0. This requires sub-nanosecond timing, specialized glitch hardware (such as a ChipWhisperer or NewAE Husky), and significant trial-and-error.
• Electromagnetic fault injection (EMFI): A focused EM pulse delivered through a micro-probe above the die can achieve similar glitch effects without touching the power rails.
• UV exposure (older parts): Very early STM32F1 devices stored option bytes in a flash technology that could be partially reset by prolonged UV exposure after decapsulation. This does not work on newer processes.
• Cold-boot / SRAM readout: On some parts, SRAM contents survive a warm reset. If firmware decrypts sensitive data into SRAM, a fast reset-and-read sequence might capture it—but only if RDP is at Level 1, not Level 2.

These techniques are non-trivial, not guaranteed to succeed, and can permanently destroy the chip. They are relevant to security researchers and to legitimate recovery scenarios (such as medical device board recovery under documentation rules), but they are not “unlock procedures” in the way that a Level 1 regression is.

Firmware Recovery Without Unlocking the Chip

Sometimes the goal is not to unlock the STM32 itself but to recover enough information to reproduce the system. Several indirect paths exist:

• External memory readout. Many STM32 designs store configuration data, lookup tables, or even full firmware images in external SPI flash or EEPROM. Reading those components is often straightforward—see our guide on EEPROM and flash data recovery.
• Bus sniffing. If the STM32 communicates with external peripherals over SPI, I²C, UART, or CAN, capturing that traffic can reveal protocol behavior, calibration data, and application logic without touching the MCU’s internal flash.
• Board-level reverse engineering. Extracting the schematic and BOM from the PCB gives engineers enough context to write replacement firmware from scratch. This is a common approach in industrial control board reverse engineering when the original vendor is no longer available.
• Bootloader or OTA update capture. If the product has a firmware-update mechanism, intercepting the update file (from a host PC, a cloud server, or a UART bootloader session) can yield the plaintext binary—unless the update is encrypted.

Series-Specific Notes

Not all STM32 families behave identically. The table below highlights practical differences engineers encounter during STM32 unlock work:

Note the STM32L5 and U5 families introduce RDP Level 0.5—a state where debug access is open but secure-world memory remains hidden. This adds a fourth rung to the protection ladder and reflects the growing influence of TrustZone in the STM32 ecosystem.

How STM32 Compares to Other MCU Families

Engineers working across platforms often need to understand how STM32’s RDP maps to the protection models of competing parts:

• MSP430: TI’s approach uses a JTAG fuse (a physical fuse, not an option byte) and a BSL password. Once the fuse is blown, JTAG is gone permanently—similar to RDP Level 2. Details are covered in our MSP430 JTAG fuse and BSL password guide.
• PIC: Microchip’s code-protect bits vary wildly across generations. Some PIC16 parts allow partial reads even when protected. The behavior is documented in our article on PIC code-protect bits across PIC12 through PIC24.
• NXP Kinetis / LPC: NXP uses security bytes in flash rather than dedicated option bytes. The regression behavior (mass erase on unsecure) is conceptually similar to STM32 RDP Level 1. For specifics, see NXP Kinetis, LPC, and S12 security configurations.
• Renesas RL78 / RX: Renesas parts use a combination of ID codes and flash shield windows. The Renesas RL78 and RX protection and recovery page covers the details.

Practical Checklist Before Attempting an STM32 Unlock

Before you connect a debugger and start experimenting, work through this checklist:

1. Identify the exact part number. Read the markings on the package. Cross-reference with ST’s product selector to confirm the family, flash size, and package.
2. Determine the current RDP level. Connect via SWD with “connect under reset.” If CubeProgrammer can read the option bytes, you are at Level 0 or Level 1. If it cannot connect at all, suspect Level 2 or a hardware issue.
3. Decide whether you need the firmware. If you only need the hardware back, a Level 1 regression (with mass erase) is fast and free. If you need the firmware, you must explore the indirect paths or advanced techniques described above.
4. Check for external memory. Look for SPI flash, EEPROM, or FRAM on the board. These may hold critical data that supplements or even replaces internal flash contents.
5. Document everything. Photograph the board, note the debugger firmware version, and log every command you send. If the chip is damaged during the attempt, this record is invaluable for a second try on a spare unit.

When to Seek Professional Help

Most Level 1 regressions are simple enough for any engineer with an ST-Link and CubeProgrammer. But several scenarios call for specialist support:

• The chip is confirmed at RDP Level 2 and you need the firmware.
• The SWD port is unresponsive and you suspect damaged traces or a counterfeit part.
• The board is part of a larger recovery project involving schematic, netlist, and Gerber extraction from hardware.
• The design uses multiple protected ICs—for instance, an STM32 alongside a protected DSP or FPGA—and you need a coordinated approach.

RDP Level 2 is a hard limit by design. Any claim of a universal, guaranteed STM32 unlock at Level 2 should be treated with skepticism. Legitimate recovery at this level is possible on certain families and revisions, but it is never routine.

Key Takeaways

• RDP Level 0 is open. Level 1 allows hardware reuse after mass erase. Level 2 is permanent.
• The standard STM32 unlock at Level 1 is a supported, documented operation using ST’s own tools.
• Level 2 defeat requires fault injection or side-channel techniques that are family- and revision-dependent.
• Indirect recovery—external memory, bus capture, board-level reverse engineering—often provides enough data to reproduce a system without touching the MCU’s internal flash.
• Always verify the actual RDP level before planning your approach. Misidentifying Level 2 as Level 1 (or vice versa) wastes time and risks damaging the chip.

Related reading

• Oct 2026NXP LPC17 Unlock | Feasibility, Cost & Lead Time
• Oct 2026Altera IC Unlock | Families We Can Read & Recover
• Oct 2026NXP LPC11 Crack | Protection Levels & Firmware Recovery