SAM4N16C Software Reset Delay

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

 

I wonder if any of you clever people can help with a problem I am having with a SAM4N16C micro. In my exception handlers I am invoking a reset using the CorTex-M4's AIRCR register. The reset works; however, the system is stalled for over 16 seconds.

 

I would imagine this is because the Watchdog has been reset back to its default settings, and it is the Watchdog that ultimately restores normal functionality.

 

Is there a better/quicker way of resetting the micro and its on-chip peripherals?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For my Cortex-M7 processor I'm using the NVIC_SystemReset() call from the CMSIS header.  It resets without delay.  It's in core_cm7.h file and listed below for reference.  I'm sure there is something similar for the cm4.

 

Does a hard boot delay 16 seconds too, or just the soft boot?  

 

 

/**
  \brief   System Reset
  \details Initiates 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  = (uint32_t)((0x5FAUL << SCB_AIRCR_VECTKEY_Pos)    |
                           (SCB->AIRCR & SCB_AIRCR_PRIGROUP_Msk) |
                            SCB_AIRCR_SYSRESETREQ_Msk    );         /* Keep priority group unchanged */
  __DSB();                                                          /* Ensure completion of memory access */

  for(;;)                                                           /* wait until reset */
  {
    __NOP();
  }
}

/*@} end of CMSIS_Core_NVICFunctions */

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello ScottMN,

 

Thank you for the example source code. It is very similar to what I have, except mine is written in Forth. A hard reset works instantly, whether done through the JTAG interface or the reset button I have tacked on to the board.

 

I think I might have to employ a hardware solution, but I'll check that is happening on my other boards first.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmmm, odd.  I'd check the interrupts.  Perhaps something is active early in the boot process and is not being serviced properly, exiting the ISR then re-entering over and over.  But on a hard reset the external device boots normally.

 

The manual method is to "binary search" the delay.  Use an I/O pin and set it high just prior to reset as a trigger for the oscope.  Then pull the pin low very early in the reset vector and measure the time.  Next keep moving the pull low point deeper into your reset code until you find the unexpected delay.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's a very good point. I hadn't considered a hang-up somewhere in the boot code. I shall blitz if with breakpoints.

 

Thank you.