STM32F427 suddenly in Read Protected Secure Mode

[Joe.H]

Developing code / debugging 2 days ago and all was well.

This morning I attempted to flash the mcu (using ST-Link / V2) and it reported back that the Processor failed to halt.

Switched to my J-Link and it reported that the MCU was in an Active Read Protect mode.

Reading up on protection, it appears it may be in mode 2 where it it permanently locked.

If I'm reading the user manual properly, it says the protecting bytes are in the 0x1fff c00x region of memory.

I checked my MAP file and there are no operations in that memory range.

My past experience has been with Freescale/NXP MCUs (30 yrs) but I recently switched to the STM32F4 family. I will eventually implement code protection but not at this time.

I really puzzled as to why the MCU is now locked. I just lost a valuable prototype used for code development.

I would like to understand how this may have happened to make sure I guard against it in the future.

Thanks in advance for any help..

Joe

[After Forever]

Read protection activation requires preliminary flash unlock (using two keys) and option bytes unlock (another two keys) operations which can't happen by accident. If you use those two unlock sequences anywhere in your code, make sure to lock it back to be safe from unwanted flash/option bytes modifications. So, either it's unlocked flash combined with code logic error, or some unknown glitch caused by power surge or radiatiоn (:

BTW, level 2 requires writing 0xCC in the option byte, which is hard to do by accident. So I doubt about level 2.

It's also possible that it's not really RDP locked, maybe J-Link just can't connect for some reason and assumes that it's locked.

[Joe.H]

Thanks.

I feel like a real dumb-***.

I switched to another proro board and same issue.

It can't be the MCU - it's got to be me!!!

Then I realized ... my board has two STM32F427 on it and I'm attempting the work with the Slave MCU. The primary MCU was not running thereby holding the Slave's MCU (the one I was attempting to work with) reset line LO!!!

Enabled the primary MCU to run .. and now all is well.

Thanks again --

[Piranha]

Try "connect under reset". For J-Link it's described in user guide at "7.9.2.4 Type 3: Connect under Reset".