nRF52832 reset and RESETREAS is 0x00000008(LOCKUP)

[jacksong]

Hi,DevZone

I'm not Native English , sometimes can not express exactly, So, I'll provide a concise description about  the question 

1, platform: nRF52832_QFAA _E1, nRF5_SDK_13.0

2, question: nRF52832 RESET(erratic and rare) and RESETREAS is 0x00000008(LOCKUP)

3, I have read some post at devzone 

https://devzone.nordicsemi.com/f/nordic-q-a/32894/what-does-cpu-lock-up-mean-and-how-should-i-debug-this-issue/126706#126706

and 

Cortex-M4 Lockup search result from google

4, my HardFualt _Handler code and WDT_Handler code:

void HardFault_Handler(void)
{
	/* Go to infinite loop when Hard Fault exception occurs */
	if (CoreDebug->DHCSR & 1)    //check C_DEBUGEN == 1 -> Debugger Connected
	{
		__breakpoint(0);  // halt program execution here
	}

	while (1)
	{
	}
}

void wdt_event_handler(void)
{
	/* Go to infinite loop when Hard Fault exception occurs */
	if (CoreDebug->DHCSR & 1)    //check C_DEBUGEN == 1 -> Debugger Connected
	{
		__breakpoint(0);  // halt program execution here
	}
	while (1)
	{
	}
}

Kenneth awneil @

Hope someone can point out what's happen and how to dig further

Thank You

[haakonsh]

You can start by dumping the CPU registers into a log or reading them out via a debugger when you get a hardfault. 

so far the most likely cause of the CPU lockup is a hardfault while the CPU is executing the hardfault handler. So finding the original hardfault is necessary. 

Also, why have you not migrated to a newer SDK yet? 

[jacksong]

Thanks for your timely reply! and I want to consult you further.

1) I will try to print, but i'm afraid can not do it, because It's difficult to reproduce the Reset.

2) why can a new hardfault occur after hardfault was processing already? I'm confused, my HardFault_Handler is nothing except a empty loop, maybe a new interrupt was generated here, But any interrupt priority can be higher than hardfault?

3) do you mean newer SDK is more stabler? and now, Is it necessary to change the SDK before  figuring out the Root cause of Reset? (maybe i can't capture reset anymore, therefore, the specific reason cannot be verified)

[haakonsh]

1. I understand
   
   
2. I'm not quite sure how, but it was mentioned in the devzone post you linked to.
   
   

jacksong said:

do you mean newer SDK is more stabler?

Yes, a lot more stable.  

jacksong said:

and now, Is it necessary to change the SDK before  figuring out the Root cause of Reset?

The root cause might have been fixed already, SDK13 is very old. 
If the issue disappears after a migration to a newer SDK then it's not really an issue anymore right?

[Turbo J]

jacksong said:

why can a new hardfault occur after hardfault was processing already?

One example:  Corrupted stack pointer register, e.g. in a buffer overflow scenario.

The hardfault logic does the same register push onto the stack like any other interrupt/exception. If you get a problem here - because SP no longer points to valid RAM - the fault handler code will never be executed, as the core goes into lockup during the stacking.