freezing after soft reset

Kernel
1

eduardo1966 wrote on Thursday, April 18, 2019:

Hi

In my never ending quest to bring all bugs into submission, I’m facing another interesting bug.

If a start the system through a power up or a download of the development system (J-Link, GDB, Eclipse) all is well and the system runs for hours without any sort of problem.
However if I send a request through the IP to reset the system by calling NVIC_SystemReset() which in my system is defined as:

__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 */
}

The system comes up with a somewhat different behaviour.
It gets an IP address from the DHCP server in the POE switcher, it accepts connections, but does not seem to get any messages…
After some time the system freezes. When I suspend the debugger I get the picture attached. I cannot recognise what is the code presented…

Any ideas?
Does the GMAC need a ‘more powerful’ reset?
Is there any special FreeRTOS call that can provide a better result?

thanks,

2

rtel wrote on Thursday, April 18, 2019:

What does the write to AIRCR actually do and how does it differ from a
hard reset.

Your screen shot shows the system siting in a tight loop - maybe an
assert has been hit (if assert is defined as for( ;; )), or maybe you
have hit an interrupt that has a default handler assigned to do nothing,
or maybe the program counter has just run away and executed anything up
until a point where it just happened to hit a null loop.

3

eduardo1966 wrote on Tuesday, April 23, 2019:

Thanks for the answer.
Somehow the fault seems not be shown anymore. I have corrected several things in our code.
I have realised in the meantime that the GMAC controller was using one pin that is also used by the QSPI.