cancel
Showing results for 
Search instead for 
Did you mean: 

STM32L496 goes into lockup state when setting readout protection

kekon
Associate II

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 7
waclawek.jan
Super User

"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

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.

 

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

Yes, the RDP set in software matches the one read by CubeProgrammer.

waclawek.jan
Super User

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

JW

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

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

JW