nRF52 spurious resets with SDK12.2.0 - How to resolve?

RE: nRF52 spurious resets with SDK12.2.0 - How to resolve?

VishnuGS — Mon, 20 Jan 2020 20:39:04 GMT

trigerion I also have similar issue with nrf52832 getting reset around every 1200 hours of continuous operation. Can you explain what is the problem with SAADC?

RE: nRF52 spurious resets with SDK12.2.0 - How to resolve?

trigerion — Tue, 22 May 2018 06:02:30 GMT

Well, after more than 6 month, I had no spurious resets after fixing the problem with the SAADC.
I do not unterstand how the SAADC caused that problem, but it did now disappeared.

RE: nRF52 spurious resets with SDK12.2.0 - How to resolve?

trigerion — Mon, 27 Nov 2017 07:40:55 GMT

Well, it seems as if I had problems with the SAADC which was triggered by app_timer while having Softdevice enabled. I detected these problems as the current consumption was more a square instead of spikes. So far, I don't know whether this has caused the reset; will test further and report if this was the problem. Nevertheless I will open another thread as I would like to understand the SAADC problem.

RE: nRF52 spurious resets with SDK12.2.0 - How to resolve?

Hung Bui — Fri, 03 Nov 2017 10:33:14 GMT

@Daniel: Please create a new case or use PM to contact Trigerion

RE: nRF52 spurious resets with SDK12.2.0 - How to resolve?

daniel — Thu, 02 Nov 2017 10:15:26 GMT

Hi Trigerion,

Have you solved it? How? I am having the same problem, I have got reset reason 0x00000004.

Thanks

RE: nRF52 spurious resets with SDK12.2.0 - How to resolve?

MartinBL — Fri, 27 Oct 2017 07:51:56 GMT

Is the app_error_fault_handler() called from an interrupt context? Such as a BLE event handler for example? Calling flash storage functions from an interrupt isn't such a good idea as is discussed here.

RE: nRF52 spurious resets with SDK12.2.0 - How to resolve?

trigerion — Thu, 26 Oct 2017 11:28:24 GMT

Can I use fds_record_write function in app_error_fault_handler to store the information to the flash? I tried it right now and does not receive the fds_event_handler call.

RE: nRF52 spurious resets with SDK12.2.0 - How to resolve?

MartinBL — Thu, 19 Oct 2017 10:37:48 GMT

If you look inside the macros and functions you will see that:

SOFTDEVICE_EVT_IRQHandler calls
APP_ERROR_CHECK() calls
APP_ERROR_HANDLER() calls
app_error_handler_bare() calls
app_error_fault_handler()

As mentioned above, app_error_fault_handler() is declared as __WEAK in the file app_error_weak.c. This allows you to "redefine" app_error_fault_handler() in e.g. your main.c file at implement it however you want. Just make a function like this in main.c:

void app_error_fault_handler(uint32_t id, uint32_t pc, uint32_t info)
{
    // Your own implementation
}

This is now the function that will be used to handle errors by your application.

RE: nRF52 spurious resets with SDK12.2.0 - How to resolve?

trigerion — Thu, 19 Oct 2017 07:56:13 GMT

Please look e.g. at 'void intern_softdevice_events_execute(void)' or 'void SOFTDEVICE_EVT_IRQHandler(void)'; these use APP_ERROR_CHECK(). How can I override them?

RE: nRF52 spurious resets with SDK12.2.0 - How to resolve?

MartinBL — Thu, 19 Oct 2017 07:51:47 GMT

I'm not sure if I understand what you mean. APP_ERROR_CHECK() eventually calls the function app_error_fault_handler(). That function is declared __WEAK so that you can override it and create your own handler wherever you want in your project.

RE: nRF52 spurious resets with SDK12.2.0 - How to resolve?

trigerion — Wed, 18 Oct 2017 15:52:57 GMT

Can someone explain me why inside softdevice_handler.c 'APP_ERROR_CHECK' is called multiple times whereas I cannot install an own handler without modifying the SDK files? I mean, did I missed some informations about that behavior?

RE: nRF52 spurious resets with SDK12.2.0 - How to resolve?

MartinBL — Wed, 11 Oct 2017 08:46:35 GMT

Q1) Yes.

Yes, GPREGRET should be retained after a soft reset. Refer to the documentation here.

The value should only be 4 after a soft reset. Note though, that the bit might be retained if you program your device without power cycling it afterwards. Is it possible that you see "old" values in the resetreas register?

RE: nRF52 spurious resets with SDK12.2.0 - How to resolve?

trigerion — Sat, 07 Oct 2017 12:36:06 GMT

Well, I do not clear the messages, but what you mention only works when having the computer/debugger being connected at all times or?
I have defined the DEBUG symbol but still I am getting resets

I used 'sd_power_gpregret_set' to debug further. Is it sure that the GPREGRET register is not cleared when the NRF_POWER->RESETREAS register has value 0x04? How can a value of 0x04 be obtained? Jumping to address 0?

RE: nRF52 spurious resets with SDK12.2.0 - How to resolve?

MartinBL — Wed, 27 Sep 2017 15:21:30 GMT

Very strange.

Are you using J-Link RTT Viewer? In my experience the messages just don't disappear unless I clear my screen programmatically in the beginning of the application. Are you doing this? Also, even if I do clear my screen, all messages still show up in the "All Terminals" tab in RTT Viewer regardless.
Can you confirm that you have tried to define DEBUG in your preprocessor defines? I understand that you have redefined all the relevant functions without NVIC_SystemReset(), but it should be worth a shot anyway.

If none of this is helpful I think we need to have a look at your code. You can upload it in confidence in our MyPage support portal if you want that.

RE: nRF52 spurious resets with SDK12.2.0 - How to resolve?

trigerion — Wed, 27 Sep 2017 12:30:05 GMT

Well, using RTT does not help as the messages vanish when the micro controller resets himself. I tested the callbacks and they are working. But nevertheless, I get softresets and I do not call NVIC_SystemReset() at all. I also replaced all APP_ERROR_CHECK(). I do not have any further idea.

RE: nRF52 spurious resets with SDK12.2.0 - How to resolve?

butch — Wed, 13 Sep 2017 14:00:50 GMT

Is it possible that the stack pointer is not reset for a soft reset, and that a soft reset pushes the context on the stack before branching to the reset handler? So that in the reset handler, you could examine the stack at the time of the soft reset?

RE: nRF52 spurious resets with SDK12.2.0 - How to resolve?

MartinBL — Wed, 13 Sep 2017 08:02:39 GMT

Is it possible to implement some RTT printouts in assert_nrf_callback(), app_error_fault_handler(), and/or HardFault_Handler() to check whether these functions are called at all and possibly print messages before the device resets?

RE: nRF52 spurious resets with SDK12.2.0 - How to resolve?

trigerion — Thu, 07 Sep 2017 06:36:34 GMT

Can someone from nordic give some more insights for the implementation of RESETREAS register?

RE: nRF52 spurious resets with SDK12.2.0 - How to resolve?

butch — Fri, 01 Sep 2017 19:18:51 GMT

I'm just following this thread, feel free to discount my blue sky rambling. If the code just got lost and jumped to address zero (the reset vector) would RESETREAS be set to 4? I am wondering how RESETREAS is implemented in HW, since it is a register in POWER device, how does it know that some code, in the function nvic_softreset(), twiddled the AIRCR register to reset the cpu? Also, is a reset from the debug hw marked as a soft reset 4 in RESETREAS or not noted at all? Also, the "CPU lockup" in the "Reset behavior" section, how does that manifest in RESETREAS, or not at all? Finally, I just read the blog here about the Jumper emulator, which might find strange HW problems. Could you emulate your system faster than the system itself actually runs and find your spurious reset in less time?

RE: nRF52 spurious resets with SDK12.2.0 - How to resolve?

trigerion — Fri, 01 Sep 2017 15:55:24 GMT

Well, I thought that implementation of 'assert_nrf_callback(uint16_t, const uint8_t*)', 'app_error_fault_handler(uint32_t, uint32_t, uint32_t)' and 'HardFault_Handler(void) would be enough. Why should I define DEBUG and DEBUG_NRF if I redefined the functions in my main.c?

RE: nRF52 spurious resets with SDK12.2.0 - How to resolve?

Hung Bui — Thu, 31 Aug 2017 15:39:55 GMT

Have you made sure it's not called from one of the app_error_fault_handler() or app_error_fault_handler() ? Please define DEBUG and DEBUG_NRF in the preprocessor setting. To avoid softreset in the assert handler.

RE: nRF52 spurious resets with SDK12.2.0 - How to resolve?

trigerion — Thu, 31 Aug 2017 12:06:04 GMT

Well, today it happened again and the RESETREAS value is 0x00000004. So reset from software. But in all of my code, I have not used 'NVIC_SystemReset()'. Any further hints?

RE: nRF52 spurious resets with SDK12.2.0 - How to resolve?

trigerion — Fri, 11 Aug 2017 19:27:10 GMT

Thanks for your replies. I deleted the RESETREAS register in the bootloader until now. Thus the value was always zero :( ... Hopefully next time I will see the reason. WDT not served, could be but it is two seconds and I trigger it in 10 Hz timer event and don't use while(1) without timeout condition. BOR I can't believe as I use a Li-Po and disconnect the BLE module when measuring less than 3.2V. The main problem is that the problem does not appear often. Took days or even weeks, thus debugging via debugger is very hard to achieve. I use four modules in parallel to have a better probability ...

RE: nRF52 spurious resets with SDK12.2.0 - How to resolve?

butch — Thu, 10 Aug 2017 12:44:48 GMT

Do you have any soft resets in your code? (If not, it must be a hard reset, either from the reset pin or from PowerOnReset POR or BOR if your Vcc falls below 1.7V temporarily?)

Do you have brownout detection implemented? You could write a flag in flash (UICR) in your brownout handler. Note that the system disables flash when it brownouts, but in your handler, you can reenable it. Since you have a battery, I would not expect a brownout but maybe your Vcc has a glitch, a brief dip.
Have you read RESETREAS register?

Do you have a power analyzer instrument?

(I also have struggled with solar powered radio, w/o a battery. It is tough.)

RE: nRF52 spurious resets with SDK12.2.0 - How to resolve?

Hung Bui — Thu, 10 Aug 2017 12:42:09 GMT

Hi Trigerion,

I assume the issue doesn't happen if you run in debug mode (and set break point in assert handler) ?

You should also check the reset reason (RESETREAS register) when booting up, so you can find the reason of the reset. Is there any possibility that the solar power was not able to provide enough power to keep the chip running ? Or some latency causing the WDT not being served ontime ?