We have a device which is used with NXP1115/303 MCU(cortex M0 core). Application doesn't do much, most of the time it sleeps in the deep power mode since the device is on 3V lithium batery. The system do a soft reset every 30sec. Reset is implemented via Reset Control Register by setting SYSRESETREQ attribute(NVIC_SystemReset function):
__STATIC_INLINE void NVIC_SystemReset(void){ __disable_irq(); __DSB(); SCB->AIRCR = ((0x5FAUL << SCB_AIRCR_VECTKEY_Pos) | SCB_AIRCR_SYSRESETREQ_Msk); __DSB();
__STATIC_INLINE void NVIC_SystemReset(void)
{
__DSB();
SCB->AIRCR = ((0x5FAUL << SCB_AIRCR_VECTKEY_Pos) |
SCB_AIRCR_SYSRESETREQ_Msk);
for(;;) /* wait until reset */ { __NOP(); }}
for(;;) /* wait until reset */
__NOP();
}
The Reset Handler looks like this:
Reset_Handler PROC EXPORT Reset_Handler [WEAK] IMPORT __main LDR R0, =__main BX R0 ENDP
Reset_Handler PROC
EXPORT Reset_Handler [WEAK]
IMPORT __main
LDR R0, =__main
BX R0
ENDP
SystemInit is at the beggining of the main function.
The issue is that MCU sometimes hangs up after the reset procedure. But it's not every time. It hangs up quite randomly, approx. 1 out of 100k(or even more) resets. It's clear that it doesn't hang up in the SystemInit or in the main. It's not really clear what is happening with the MCU at the hang up state, but it looks like it is in lock up state.
Some known information:
Is there any suggestions which can be tried? Any ideas is welcome!
If the power is 3, 4 mA, there might be an issue of clock reset generation in the chip.
Which clock source is being used? (is PLL being used?)
Before the soft reset, try changing the clock back to internal RC oscillator first (without going through PLL).
regards,
Joseph
Thank you, Joseph for reply!Yes, the power is 3V. Unfotunately the clock source being used is IRC, so the PLL isn't used.
If it would help, the same thing happens even when reset is made by WDT (feeding the wrong sequence) instead NVIC_SystemReset.Is there any other ideas?
Unfortunately I guess we need someone from NXP to look into this. Try post the question to
https://community.nxp.com/
and see if someone from NXP can help.
There is some updates regarding this case, but still the solution not clear.
We have attached MCU debugger to device which was in hang-up state and discovered, that it was stuck in HardFault handler of Boot ROM application (@0x1FFF0000-0x1FFF4000).Attached is a screenshot of our debug session with useful HardFault related information with stack frame exposed (@0x10001FB0).
Do you have any thoughts on this case?