NVIC_SystemReset in interrupt

[zexx86]

Posted on August 07, 2012 at 23:40

Hello

I implementing something like own watchdog, but I can't reset STM32 in SysTick interrupt. It just stop SysTick interrupts but nothing more.I tried to disable interrupts before, but it is same with:__disable_irq ();NVIC_SystemReset ();Is it possible to reset it in some way while I can't do it in main loop?UPDATE: I check that NVIC_SystemReset dont work even in main loop.. Whole STM32 only stop working, but no resetting.Thanks #stm32-watchdog-system-reset

[Tesla DeLorean]

Posted on August 08, 2012 at 00:01

Would have expected that would have worked, but haven't tried.

What about something like :

IWDG_WriteAccessCmd(IWDG_WriteAccess_Enable);
IWDG_SetPrescaler(IWDG_Prescaler_4);
IWDG_SetReload(2);
IWDG_ReloadCounter();
IWDG_Enable();
while(1);

[Tesla DeLorean]

Posted on August 08, 2012 at 00:03

You don't have something external driving the RESET high?

[zexx86]

Posted on August 08, 2012 at 00:10

I am afraid, but it does not help - result is same like with NVIC_SystemReset.

I don't have any pin routed to RESET.. I think something is blocking request for resetting. I use 2 timers, 2 usarts, 1 i2c and some gpios. External crystal and nothing special. Systick is configured with SysTick_Config (SystemCoreClock / 10000); Meybe I have to disable all peripherals first.

[tlamotte9]

Posted on September 24, 2014 at 12:09

Dear all,

Just to give you a feedback because I ran into issues when I tried to make the NVIC_SystemReset work: it did not... I guess I found why and so far I fixed it: On my side, invoking NVIC_SystemReset() did not work properly. So I tried writing the routine in assembly language just like Clive advised us:                 AREA |.text|, CODE, READONLY                 THUMB                 ALIGN   SystemReset     PROC                 EXPORT  SystemReset [WEAK]                 ldr     r1, =0xE000ED0C ; NVIC Application Interrupt and Controller                 ldr     r0, =0x05FA0004 ; Magic                 str     r0, [r1, #0]    ; Reset self            b       self                 bx      lr                 ALIGN                 ENDP                 END   The outcome is that this code works well. So what's the differences between the code of the NVIC_SystemReset: Maybe this: In assembly: - first we write the magic word - secondly we request the reset Meanwhile in the NVIC_SystemReset() function, we try to do both in the same writing operation. So, let's try it: I retouch the NVIC_SystemReset() in the CMSIS file core_cm3.h (for me) like this: /** \brief  System Reset     The function initiates a system reset request to reset the MCU.  */ __STATIC_INLINE void NVIC_SystemReset(void) { /* Ensure all outstanding memory accesses included     buffered write are completed before reset */   __DSB();                 SCB->AIRCR  = ((0x5FA << SCB_AIRCR_VECTKEY_Pos) |      /* Magic word */                  (SCB->AIRCR & SCB_AIRCR_PRIGROUP_Msk));       /* Keep priority group unchanged */   SCB->AIRCR  = SCB_AIRCR_SYSRESETREQ_Msk;  /* Request system reset */   __DSB();                                                          while(1);                                                    /* wait until reset */ } Now, NVIC_SystemReset() works perfectly... Best regards, Thierry

[stm322399]

Posted on September 24, 2014 at 14:43

While I appreciate people sharing their experience, in particular successes, I would like to go deeper, because I do not understand at all how this solved your problem. The worst being that you may think it is solved whereas there is still a bug hidden.

First, the assembly code writes the magic word and the request in a single operation, which is close to the behaviour of the original NVIC_SystemReset function. Second, your modification of the NVIC_SystemReset function is a bad idea, and won't work on most projects because it will produce two writes to the register, and the second write (with reset request) will be ignored by the processor because it does not contain the magic word. Could you please double check that your modification has the claimed positive effect ? If yes, I would strongly recommend you to clarify the situation (looking at the assembly code generated) because your modification should have lead to the opposite (no more reset).