Skip to main content
Associate
September 16, 2026
Solved

Unable to unlock RDP1 and regress to RDP=0 through the command line, but am able to through the GUI

  • September 16, 2026
  • 2 replies
  • 71 views

I am working on a batch script to disable TrustZone on an STM32U595VJT connected via JLINK using the STM32CubeProgrammer CLI tool.

The device has both OEM1KEY and OEM2KEY set to [31:0] = 0xABCDEFAB, [63:32] = 0x12345678

I am trying to run the following command when the RDP level is 1 and TrustZone is enabled with the device booted into the root secure services:

STM32_Programmer_CLI.exe -c port=JLINK mode=HotPlug reset=HWrst freq=4000 ap=0 speed=Reliable -unlockRDP1 0xABCDEFAB 0x12345678 -ob RDP=0xAA TZEN=0

The command fails to set the RDP level and TZEN flag with the following output:

      -------------------------------------------------------------------
STM32CubeProgrammer v2.20.0
-------------------------------------------------------------------

Connecting to J-Link/Flasher Probe
Warning: The frequency input is not supported by the connected J-Link/Flasher !
Device=Cortex-M33

Unlock RDP1 password successfully done
Device ID : 0x481
Voltage : 3.33V
Frequency : 3847 KHz
Flash size : 4 MBytes

UPLOADING OPTION BYTES DATA ...

Bank : 0x00
Address : 0x40022040
Size : 48 Bytes

██████████████████████████████████████████████████ 100%


PROGRAMMING OPTION BYTES AREA ...

Bank : 0x00
Address : 0x40022040
Size : 48 Bytes

▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒



Reconnecting...
Reconnected !


UPLOADING OPTION BYTES DATA ...

Bank : 0x00
Address : 0x40022040
Size : 48 Bytes

██████████████████████████████████████████████████ 100%

OPTION BYTE PROGRAMMING VERIFICATION:

Error: Expected value for Option Byte "rdp": 0xAA, found: 0xDC
Error: Expected value for Option Byte "tzen": 0x0, found: 0x1
Error: Option Byte Programming failed Or modified by application after OB_LAUNCH

However, if I connect to the device in the GUI tool, unlock RDP1, then disconnect from the GUI tool and re-run the above command, then the command succeds:

      -------------------------------------------------------------------
STM32CubeProgrammer v2.20.0
-------------------------------------------------------------------

Connecting to J-Link/Flasher Probe
Warning: The frequency input is not supported by the connected J-Link/Flasher !
Device=Cortex-M33

Unlock RDP1 password successfully done
Device ID : 0x481
Voltage : 3.33V
Frequency : 3847 KHz
Flash size : 4 MBytes

UPLOADING OPTION BYTES DATA ...

Bank : 0x00
Address : 0x40022040
Size : 48 Bytes

██████████████████████████████████████████████████ 100%


PROGRAMMING OPTION BYTES AREA ...

Bank : 0x00
Address : 0x40022040
Size : 48 Bytes

▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒



Reconnecting...
Reconnected !


UPLOADING OPTION BYTES DATA ...

Bank : 0x00
Address : 0x40022040
Size : 48 Bytes

██████████████████████████████████████████████████ 100%

OPTION BYTE PROGRAMMING VERIFICATION:

Option Bytes successfully programmed
Time elapsed during option Bytes configuration: 00:00:02.966

This leads me to believe that somehow the CLI tool is failing to unlock RDP1 like the GUI tool is able to do.

Here’s a screenshot of my settings in the GUI tool, all the settings line up with my CLI arguments as far as I can tell:

 

My IWDG and WWDG option bytes are also checked, so the watchdog shouldn’t be interfering with the unlock process.

Am I missing something? Are there any other steps I need to perform to unlock RDP1 through the command line?

Best answer by Adam G

Hi Moktar SELLAMI, Thanks for the reply.

When I run these two commands back-to-back I get the same result, the first command indicates that the unlock of RDP1 was successful, and then the second command indicates that the option bytes failed to update.

If instead of running the first command I open the STM32CubeProgrammer GUI, connect, unlock RDP1, then disconnect, then when I run the second command it reports that the option bytes were successfully programmed.

I did notice there’s a newer version of STM32CubeProgrammer available, v2.23.0 where I was using v2.20.0. I installed the newer version and now the command to unlock the RDP OEM1KEY is working, so I guess it was just an issue with the older software.

2 replies

Moktar SELLAMI
ST Employee
September 17, 2026

Hello ​@Adam G

According to RM0456, section 7.6.2, RDP protection state, OEM1 RDP lock, to regress from RDP1 to RDP0 when RDP1 is locked, the following sequence must be applied:

  • Unlock the RDP 1 using OEM1Key. 
  • Perform the RDP regression 

 

 

Therefor, as the AN5347 section10: Demonstration of RDP transitions using OEM keys on STM32U5, demonstrated, specifically step 11 and step 12.  This is the process to follow:

1- First unlock the RDP level 1 using RDP OEM1KEY

STM32_Programmer_CLI.exe -c port=JLINK mode=hotplug -unlockrdp1 0xABCDEFAB 0x12345678

2- Then perform RDP regression 

STM32_Programmer_CLI.exe -c port=JLINK mode=hotplug -ob rdp=0xAA tzen=0
 

Sincerely, 
Moktar SELLAMI.

Adam GAuthorBest answer
Associate
September 17, 2026

Hi Moktar SELLAMI, Thanks for the reply.

When I run these two commands back-to-back I get the same result, the first command indicates that the unlock of RDP1 was successful, and then the second command indicates that the option bytes failed to update.

If instead of running the first command I open the STM32CubeProgrammer GUI, connect, unlock RDP1, then disconnect, then when I run the second command it reports that the option bytes were successfully programmed.

I did notice there’s a newer version of STM32CubeProgrammer available, v2.23.0 where I was using v2.20.0. I installed the newer version and now the command to unlock the RDP OEM1KEY is working, so I guess it was just an issue with the older software.