Skip to main content
Associate II
Jan 29, 2026 9:54 AM UTC
Question

STM32L496 goes into lockup state when setting readout protection

Hello, 

I have a problem with setting readout protection in the STM32L496 device in software. The protection is set to "BB". After setting and power on reset, the microcontroller seems to not work (it looks like as if it was "stuck up"). I connected the ST-Link programmer and run STM32Cube programmer and it shows option byte RDP set correctly to BB value. Also, in the FAULT ANALYZER section it displays "CPU: LOCKUP". I don't know why it happens and how to solve it. The software code that sets the RDP protection is shown below:

 

 __disable_irq();
	while (FLASH->SR & FLASH_SR_BSY);

	FLASH->KEYR = 0x45670123;
	FLASH->KEYR = 0xCDEF89AB;
	FLASH->OPTKEYR = 0x08192A3B;
	FLASH->OPTKEYR = 0x4C5D6E7F;

	FLASH->OPTR = 0xFFEFF8BB;

	FLASH->CR |= FLASH_CR_OPTSTRT;
	while (FLASH->SR & FLASH_SR_BSY);
	FLASH->CR |= FLASH_CR_OBL_LAUNCH;

 

7 replies

waclawek.jan
Super User
Jan 29, 2026 11:43 AM UTC

"CPU:LOCKUP" may be result of attempting to debug the RDP-protected mcu.

If you don't set RDP1 through your program, but e.g. using CubeProgrammer, does your program run after power-on reset?

If not, the problem is not in the code you presented above. Debug e.g. by outputting debug printouts at strategic places, or just blink LED, i.e. without involvement of the debugger.

JW

kekonAuthor
Associate II
Jan 29, 2026 12:00 PM UTC

If the RDP is set in the CubeProgrammer, the device works properly but when it is set in the software

the problem exists even if the debug probe (ST-Link) is disconnected. Power on reset doesn't help either. I can confirm that because STM32 drives TFT display and many other components, and I can see that they don't receive any signals from the STM32.

 

waclawek.jan
Super User
Jan 29, 2026 2:10 PM UTC

If you set RDP in software, power-off-on and then read out the Option bits by CubeProgrammer, do they match the Option bits read out after you set RDP by CubeProgrammer?

In other words, is there a difference between Option bits for the working and non-working case?

JW

waclawek.jan
Super User
Jan 29, 2026 3:05 PM UTC

I mean, compare *all* option bits, not just the one byte determining RDP.

JW

kekonAuthor
Associate II
Jan 30, 2026 7:28 AM UTC

I compared all of  them, and they match. Some time ago I also programmed the rest of option bytes writing default values which are set in "factory fresh device" (shown in the programmer) but it didn't work.

waclawek.jan
Super User
Jan 30, 2026 10:10 AM UTC

Then IMO the only option is the painful way of debugging without debugger as I've outlined above. Sorry.

JW