Software Reset on STM32F417 - Doesn't Work?

[kevin23]

Posted on October 21, 2013 at 22:53

Hi All,

I am working with the STM32F417. I am developing a bootloader and I need to generate a software reset. According to the Cortex-M4 programming manual (PM0214), you can generate a software reset by writing to the AIRCR register in the System Control Block. It appears that the only bit available to for a reset is bit 2, SYSRESETREQ. Bits 1 and 0 are reserved. So, including the VECTKEY, I have the following line of code: SCB->AIRCR = 0x05FA0004; It does not do anything. It definitely does not reset the microcontroller. I have tried with and without connection to the debugger. No difference. I cannot find any entries on the forum about software resets on the Cortex-M4. Apparently the Cortex-M3 libraries have routines called NVIC_SoftwareReset, and/or NVIC_GenerateSoftwareReset. My libraries do not include these functions. I can confirm that bit 0 of the CONTROL register is 0, indicating that I am in privileged mode so I am allowed to write to the AIRCR register. Are there any steps/actions need to take right before, or right after the write to AIRCR? There is nothing in the errata about this software feature. Thanks Kevin #aircr #stm32 #software-reset

[kevin23]

Posted on October 22, 2013 at 00:41

UPDATE:

So I found the NVIC_SystemReset function in ''core_cm4.h''. The code is copied below.

 When I call this function, it just sits forever in the while(1) loop, indicating that it is NOT working.

/** \brief  System Reset

    This function initiate a system reset request to reset the MCU.

 */ static __INLINE void NVIC_SystemReset(void) {   __DSB();                                                     /* Ensure all outstanding memory accesses included                                                                   buffered write are completed before reset */   SCB->AIRCR  = ((0x5FA << SCB_AIRCR_VECTKEY_Pos)      |                  (SCB->AIRCR & SCB_AIRCR_PRIGROUP_Msk) |                  SCB_AIRCR_SYSRESETREQ_Msk);                   /* Keep priority group unchanged */   __DSB();                                                     /* Ensure completion of memory access */   while(1);                                                    /* wait until reset */ }

[Tesla DeLorean]

Posted on October 22, 2013 at 00:55

Are you using an RTOS by chance?

Are you driving the NRESET pin externally with a Push-Pull driver?

[kevin23]

Posted on October 22, 2013 at 16:29

No RTOS, but we sure are driving nRESET with a push-pull. It is tied to the output of an AND gate. I had checked for that issue early in my troubleshooting but missed it.

We'll have to change the circuit. Thanks Clive!

[Tesla DeLorean]

Posted on October 22, 2013 at 16:53

Had kind of discounted the RTOS as you'd already looked at the Privilege level.

Seen a bunch of ARM designs where the RESET fails like this, you're not the first, or likely the last. I had one customer complain my board was resetting his system, as I was using a thresholding POR chip attached to my RESET pin which didn't care for his supply browning out all the time.