Problem with NVIC_SystemReset() after FLASH_ReadOutProtection(ENABLE)

[rgrimes]

Posted on July 28, 2015 at 23:04

I'm trying to set Flash read protection, so I run this at startup:

if (FLASH_GetReadOutProtectionStatus() != SET) {
FLASH_ReadOutProtection(ENABLE);
}

This works wrt read protection, in that if I connect later with an ST-Link, it complains correctly that it cannot read from Flash. This is good. However, if I later call NVIC_SystemReset(), the processor seems to hang, and I can't connect to it to find out where it is stuck - because of the red protection. If I do not set the read protection programmatically, but set it using ST-Link, everything works fine. However, I'd like to avoid that extra step. By the way, this is with the STM32F The same code (different library code, of course) works correctly on the STM32F Any thoughts? Thanks!

[rgrimes]

Posted on July 29, 2015 at 01:37

More information. It turns out that after I power cycle (actually remove power, not simply toggling the RESET line) the processor, NVIC_SystemReset() works properly!

This is very much better, but still not ideal. It isn't cool to have to power cycle just to get things working! And back to the ST-Link - when the read protection is applied by ST-Link, everything works. Now, I'm not at all aware of how the debug interface works, but if the processor is involved somehow, it would seem it is setting the protection bits, yet everything works fine, without a power reset. So I wonder if there is some missing ''special sauce'' operation that I'm missing? (While I'm at it, I should note the full code here; this is the extent of what I'm doing wrt flash protection)

void protectFlash()
{
// Unlock Flash and option bytes
FLASH_Unlock();
// Enable read protection for all of flash
if (FLASH_GetReadOutProtectionStatus() != SET) {
FLASH_ReadOutProtection(ENABLE);
}
// Enable write protection for the bootloader
if (FLASH_GetWriteProtectionOptionByte() == 0xffffffff) {
FLASH_EnableWriteProtection(FLASH_WRProt_Pages0to1 | FLASH_WRProt_Pages2to3);
}
// Relock Flash
FLASH_Lock();
}

Am I getting close? Is there something else I should do after setting the protections? FWIW - the

FLASH_EnableWriteProtection

function is not a problem, as everything works the same with or without it in place; I'm including this for completeness. Thanks!

Posted on July 07, 2016 at 11:17

Hi robert,

have you found a solution to this ?

I ve been running into exactly the same problem now.

best regards

[AvaTar]

Posted on July 07, 2016 at 13:20

A suggestion unrelated to Flash protection - check that your system reset actually succeeds.

If not, the core might cycle in the hardfault handler. Had such a case recently, when the core peripheral address range (including SCB) was protected by the MPU.

[adam23]

Posted on September 13, 2016 at 07:27

I have the same problem. When FLASH_ReadOutProtection is called the CPU gets stuck. Thanks to the reply that it could be due to HardFault - I found it really ended up in HardFault handler, but this handler ends up with NVIC_SystemReset(), but this reset is not performed either. CPU just halts somehow and this is it. It has to be power-cycled to run again. The protection is set anyway... I put the FLASH_ReadOutProtection(ENABLE) before the MPU setup, but it did not change anything regarding reset.

[adam23]

Posted on September 13, 2016 at 13:14

Seems that as soon as RDP is set, the only way to start the device is to do a POR. It is not enought to do any kind of system reset. Even thou there is this in Flash Programming manual for STM32F103:

2.4.1 Read protection

The read protection is activated by setting the RDP option byte and then, by applying a

system reset to reload the new RDP option byte.

Note: If the read protection is set while the debugger is still connected through JTAG/SWD, apply a

POR (power-on reset) instead of a system reset (without debugger connection).

I was not able to find a way to use a system reset after RDP is set.

[TalashMe]

Hi I have also similar problem,

I am using an STM32L010T6 chip and facing difficulty with first-ever bootup.

For the first-ever bootup vector interrupt not working until the hardware reset happens.

Thanks in advance