nRF52832 reset and RESETREAS is 0x00000008(LOCKUP)

RE: nRF52832 reset and RESETREAS is 0x00000008(LOCKUP)

Turbo J — Tue, 21 Jul 2020 09:26:18 GMT

[quote userid="14621" url="~/f/nordic-q-a/63942/nrf52832-reset-and-resetreas-is-0x00000008-lockup/260871"]why can a new hardfault occur after hardfault was processing already? [/quote]

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.

RE: nRF52832 reset and RESETREAS is 0x00000008(LOCKUP)

haakonsh — Tue, 21 Jul 2020 09:02:21 GMT

I suggest you also log the cpu registers to flash in the hardfault handler.

RE: nRF52832 reset and RESETREAS is 0x00000008(LOCKUP)

jacksong — Tue, 21 Jul 2020 01:52:52 GMT

Hi,

In thsi case, the Reset was capture from daily use of product instead of simulation debug. I make a simple flash system on extern-SPI-flash, which can save RESETREAS and other necessary message as soon as chip reset. the LUCKUP shown to you is readback from flash.

RE: nRF52832 reset and RESETREAS is 0x00000008(LOCKUP)

Turbo J — Mon, 20 Jul 2020 19:16:15 GMT

[quote userid="14621" url="~/f/nordic-q-a/63942/nrf52832-reset-and-resetreas-is-0x00000008-lockup"]RESETREAS is 0x00000008(LOCKUP)[/quote]

How do you know that?

I am asking because Segger RTT logging internally enables debug registers. Which means those breakpoint instruction will be executed, and directly trigger the Lockup (fault in Hard Fault condition).

RE: nRF52832 reset and RESETREAS is 0x00000008(LOCKUP)

haakonsh — Mon, 20 Jul 2020 17:28:53 GMT

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

[quote user="jackstraw"]do you mean newer SDK is more stabler? [/quote]

Yes, a lot more stable.

[quote user="jackstraw"]and now, Is it necessary to change the SDK before figuring out the Root cause of Reset?[/quote]

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?

RE: nRF52832 reset and RESETREAS is 0x00000008(LOCKUP)

jacksong — Mon, 20 Jul 2020 16:34:30 GMT

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)

RE: nRF52832 reset and RESETREAS is 0x00000008(LOCKUP)

haakonsh — Mon, 20 Jul 2020 14:48:57 GMT

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?