stm32f4 using NVIC_SystemReset() fails to reset

[ari_v2]

Hello,

My board consists of stm32f427 and I have a strange problem.

Calling NVIC_SystemReset() causes CPU to hang. This happens only on some boards.

I could overcome the problem in one of the following:

• Add a HAL_Delay(100) before calling NVIC_SystemReset()
• Change code in NVIC_SystemReset() as follows:

   SCB->AIRCR = ((0x5FA << SCB_AIRCR_VECTKEY_Pos) |

               (SCB->AIRCR & SCB_AIRCR_PRIGROUP_Msk) |

             SCB_AIRCR_SYSRESETREQ_Msk |               

SCB_AIRCR_VECTCLRACTIVE_Msk | SCB_AIRCR_VECTRESET_Msk)

   These 2 additional bits cause CPU to reset, although they are meant to be used only for debug

• Of course system will reset if I use the IWDG.

I read in forums that others encountered this problem but in my case it looks different:

• NRST pin has a pulldown 0.1uF.  NRST is not pulled up. As shown below in figure
• BOOT0 is connected to ground. 

Could anyone please explain:

Why NVIC_SystemReset() does not work on some boards?

How could the delay of 100 msec or setting system control register bypass the problem?

Thank you,

Ari

[Tesla DeLorean]

Failure of reset is almost always due to something external driving the NRST and preventing it getting LOW.

This could be some external device sharing the pin, perhaps another chip, another plug-in board, or a defective debug pod

[ari_v2]

Thanks for reply.

I doubled checked that. Nothing prevents NRST from getting low.

Also it is really strange that a delay of 100 msec before calling NVIC_SystemReset() bypasses the issue...

[Tesla DeLorean]

Yes, but does it actually reset and fail somewhere else after it re-enters Reset_Handler? Have code right in the front section of Reset_Handler toggle or signal via a GPIO.

[ari_v2]

It does not reset. I probe the NRST and see that line is kept HIGH (if I add the delay it goes LOW).

Using the debugger -

if I stop at breakpoint before call to NVIC_SystemReset(), reset is OK.

If debugger is stopped after calling NVIC_SystemReset() the PC is at address in an unexpected\invalid address. I have a breakpoint at reset handler and PC didn't reach it.

[Tesla DeLorean]

Not really clear to me how a break-point would survive a reset.

Does the problem occur without the debugger attached?

[TDK]

> Not really clear to me how a break-point would survive a reset.

Hardware breakpoints persist after reset, at least on all my IDEs. Do they not persist in Keil?

[TDK]

> Calling NVIC_SystemReset() causes CPU to hang.

What does this mean exactly? What happens when you assembly step through the code?

> This happens only on some boards.

Suggests a hardware error of some sort. Is power stable?

Could be some interaction with something else in your program. Are any pending operations going on? What does your program do?

[ari_v2]

When I assembly step in NVIC_SystemReset() the CPU resets as expected and code strat to run from reset handler.

The problem occurs if I don't stop debugger, rather I let it run and stop debugger after running NVIC_SystemReset() the PC is at 0 or other unexpected address.

Yes, power is stable.

What does your program do?

The program resides at address 0x800c000 and programs flash at 0x8008000 with code. After verifying that programming succeeded, it performs the above mentioned reset. Here it gets stuck.

If I power reset the board - everything works as expected.

Thank you

[ari_v2]

The main point is that if code runs without break point, NRST is not pulled low and if I stop running (via debugger) PC is an invalid address.

The problem occurs also without debugger connected.

[TDK]

Only thing I can guess is if there's some flash operation still ongoing that is affecting things.

[Tesla DeLorean]

All very odd, don't have an explanation here.

Did you stop something else just prior to doing the reset? Flash Write or Erase? Turn off a PWM?

Is the capacitor really 100nF (0.1uF) and not something much larger?