STM32F030 Locks up after being placed in Level 1 Flash security mode by Option byte

[Joe.H]

Main is entered,

(for testing I enable the GPIO and turn on an LED to validate that cpu execution has entered main() --- then

I set up the PLL, and GPIO - then test if the MCU has option byte set for Level 1 - if not I set it.

I reset the device and it appears to be non-functioning.

After reset - main() is never entered because the LED is not turned on.

So - what can happen to the CPU such that after the option byte is changed (from AA 55 to 11 EE) - thereby have the MCU enter level 1 flash security that it appears to lock up?

The MCU hardware has BOOT1 pin tied to ground so the boot process is supposed to boot to the user program in flash memory.

I did find something in the user's manual about "Empty Check" which detects that flash at location 0x08000 0000 is 0xffff ffff - it assumes the flash is totally erased and causes the boot process to jump to the internal ST bootloader. If this WAS happening, it would present the same behavior I am having but I don't understand how the MCU would have all of the flash erased simply by programming the option byte to 11 ee.

Can someone explain why the MCU appears to be not running my program or is off running someplace else?

Thanks

[Joe.H · Accepted solution]

I started a deep dive into the assembler startup file and found the issue.

The startup file expected a debugger to be present so the reset entered an endless loop and was only allowed to proceed with intervention from the debugger. This enabled an on-start break point to work.

I disabled the debugger assisted reset and all works as expected now.