Core is locked up after programming option bytes with CLI programmer

[Bitschubse]

I use a STM32L412 on a custom board.

I have a programing script for our production which calls STM32_Programmer_CLI.exe for downloading a hex file and also some parameters to program the option bytes:

STM32_Programmer_CLI.exe -c port=SWD freq=24000 mode=PowerDown -d example.hex -v -ob SRAM2_PE=0 SRAM2_RST=0 BOR_LEV=1 WRP1A_STRT=0x0 WRP1A_END=0x3d RDP=0xBB -ob displ -rst -score

Everything works fine, the option bytes are shown correctly, but at the end it says:

MCU Reset
 
Software reset is performed
Core is locked up

The device is dead. Only a power cycle helps to come out of this.

Has anybody an idea, what I am doing wrong here? I already tried some different reset or run commands, but nothing helps. The device stays locked.

I guess, the problem is with setting the read out protection.

I tried to set the option bytes in the firmware at startup, when I set the OBL_LAUNCH bit, I also get a lock or the system seems to boot in the system memory, because the PC register is something like 0x1FFF2xxx. But I am not sure.

Is not a real big problem, because a power cycle solves it, but want to understand, what I am doing wrong or if it is a "feature" of the chip.

I also tried this after running the script above

STM32_Programmer_CLI.exe -c port=SWD freq=24000 mode=PowerDown -ob displ -rst -score

But it also locks the core.

[Chloe Meunier]

Hello,

did you try with an other mode? for example mode = hotplug?

BR

Chloé

[Bitschubse]

Hi,

yes I tried all the other modes, but only UR and PowerDown works. With Hotplug and Normal, it says, that no STM32 device is found.

[Chloe Meunier]

Ok you programmed RDP level 1. What do you mean by "the core is locked"? you can't read anything from the chip? the code you downloaded doesn't run?

BR

Chloé

[Bitschubse]

The programmer tells, the core is locked up. See above. I see, that my code does not start. I can still read the option bytes but not the flash, but that is what I wanted with RDP level 1.

If I disconnect the device from power and connect it again, the code runs. But I want that it starts directly after the command without cycling power.

[Bitschubse]

No idea?

[Bob S]

When the chip is configured for either RDP1 or RDP2, *ANY* attempted access via JTAG/SWI will lock the core. That is by design, and it is how RDP1/2 prevent outside access to FLASH and RAM. The programmer is trying access the chip after reset, which triggers the lock. This is normal behavior. You always need to power cycle after programming RDP1 or RDP2.

[Bitschubse]

Hi. Still having this problem in my app but I found out some new things:

If I change the option bytes in the code of the application which is in the flash, the device hangs after setting the OBL_LAUNCH bit. It does not matter which option bytes are changed. In this special scenario, I leave the RDP unchanged. If I try to debug it, the debugger connection gets lost when setting OBL_LAUNCH.

Now I have a application, which is in RAM1. With this, I have no problems changing the option bytes. After setting the OBL_LAUNCH bit, the system resets and runs. It does not matter if the ram application runs in user mode (started from a flash app) or via the boot configuration in system mode.

It seems that there is something different between the flash app and the ram app but the code is the same.

Any idea what is going wrong in the flash app?

EDIT: Sorry, forget the question. The debugger is kicked out but the application starts. Hang ups are only while setting the RDP register.