Spurious restarts on nRF52832 with ble_app_uart example if no BLE device connected

[viktor.kz]

I was developing application very similar to the basic ble_app_uart_pca10040_s132 example when I started getting random restarts and Segger Embedded Studio breaks at a strange location. Without SES the device just restarts without breaking after several minutes.

This happens also with the stock ble_app_uart example and the stack and memory range are weird (not sure from memory map where they actually belong).

RESETREAS is always 0x10004 which seems that the reset is from software.

It never hits the asserts or app_error_handler or app_error_fault_handler though like here.

I tried to debug it by stepping, but that causes softdevice to memfault.

The call stack and disassembly where SES breaks looks like this always:

It also does not seem to be any of the faults like HardFault.

Then the code continues back to main().

Weirdest part is that the restarts do not happen if a BLE device is connected to the Nordic UART. Only if no device is connected, then after several minutes it restarts.

[Vidar Berg]

Hello,

Do you see the same if you comment the call to sleep_mode_enter() here:

?

It's here the example tries to enter system OFF mode (deep sleep) after advertising has timed out after 3 minutes of inactivity. It's however not possible to enter System OFF mode while the chip is in debug mode, so this will lead to an assertion and cause the program to reset in the default error handler.

Note that you can use the "Debug" build configuration to get more error information from the fault handler (crashlog is printed out on RTT):

And you can disable the "Reset" breakpoint if you don't want the CPU to halt on the reset handler in the MBR (Master boot record):

Best regards,

Vidar

[viktor.kz]

Thank you very much!

Wouldn't have guesses that calling sleep actually resets the board. I've searched for any instances of call to reset or NVIC_SystemReset, but didn't find any.

I've been working with ARM-based CPUs for about 10 years, but never have I encountered one like nRF where you can't use breakpoints/stepping since it causes softdevice to throw memory fault.

I wanted to make use of ARM ETM TRACE in Ozone with JTrace, but my board has incorrectly routed TRACE pins (needs new revision). Which would be very helpful in seeing where the program went before it reset/crashed.

RTT or SystemView will get you only so far.

Vidar Berg said:

It's however not possible to enter System OFF mode while the chip is in debug mode, so this will lead to an assertion and cause the program to reset in the default error handler.

I've tried to break on the app_error_handler or app_error_fault_handler, but neither breakpoint is hit.

Vidar Berg said:

Note that you can use the "Debug" build configuration to get more error information from the fault handler (crashlog is printed out on RTT):

I was using Debug configuration, but I can't see any crashlog printo into RTT, it just looks like this (can't see any information like Ozone would show about fault handler, any idea why?):

EDIT:

Here is how it looks like when I use Debug configuration and also enable debug messages via RTT, still no crashlog:

Best regards,

  Viktor

[Vidar Berg]

Hi Viktor,

viktor.kz said:

I've been working with ARM-based CPUs for about 10 years, but never have I encountered one like nRF where you can't use breakpoints/stepping since it causes softdevice to throw memory fault.

My experience is mostly with the nRF series. But I don't think this is an uncommon limitation when dealing with protocol stacks that has real-time requirements. In any case, the Softdevice should invoke the application's error handler when this happens, and then let the application handle the error. The Softdevice should never perform a soft reset by itself.

viktor.kz said:

I've tried to break on the app_error_handler or app_error_fault_handler, but neither breakpoint is hit.

This is strange. Can you confirm that app_error_fault_handler() is only defined in app_error_weak.c and not redefined elsewhere in your project?

viktor.kz said:

Here is how it looks like when I use Debug configuration and also enable debug messages via RTT, still no crashlog:

Can you search through the project for "NVIC_SystemReset()" and see if it may be called anywhere else in your code?

Best regards,

Vidar

[viktor.kz]

Vidar Berg said:

Can you confirm that app_error_fault_handler() is only defined in app_error_weak.c and not redefined elsewhere in your project

Yes, I looked at linker ELF output and also tried to put symbolic breakpoint on app_error_handler and app_error_fault_handler so that it forces linker to lookup the symbol address instead of putting a breakpoint on specific line.

I can trigger the handlers when I just comment out the uart_init in the stock example by forcing an error when printf() is called and it writes out the error via RTT like expected.

But not with call to sleep.

Vidar Berg said:

Can you search through the project for "NVIC_SystemReset()" and see if it may be called anywhere else in your code?

I tried this on the stock SDK ble_app_uart example with no modifications. There is no direct call to NVIC_System_Reset. I dug deeper and found out such call would expand to __NVIC_System_Reset which is static inline, so I had to put a breakpoint at the address of inlined code where write to SCB->AIRCR register does the reset.

Adding a call NVIC_SystemReset to test it code does trigger it. Though finally I can see that there is sd_power_system_off call in sleep_mode_enter which also does the reset.

So thanks, I think we can consider this resolved.

Regards,

  Viktor

[Vidar Berg]

Hi Victor,

Thanks for the update. But I am still puzzled as to why your program doesn't appear to reach the app error handler when you get the assert in sleep_mode_enter(). app_error_fault_handler() is the only place where NVIC_System_Reset() should get called from in the original example. 

And sd_power_system_off() will either make the device enter system OFF mode (wakeup from system off is a different reset source), or return with an error code. It will not access the SCB->AIRCR register.

Regards,

Vidar

[viktor.kz]

I think we misunderstood each other here. There is no direct assert in sleep_mode_enter(), I was demonstrating it on the unmodified ble_app_uart example (which doesn't have explict assert).

Vidar Berg said:

It's however not possible to enter System OFF mode while the chip is in debug mode, so this will lead to an assertion and cause the program to reset in the default error handler.

Though this part is not what what is happening. Regardless whether Release or Debug configuration is chosen, both times sleep_mode_enter() ends up resetting without triggering any assert. I've tried this for s112 and s132 softdevices just to be sure. At least in the latest SDK_17.1.0 and gcc toolchain used as compiler.

[Vidar Berg]

I should have clarified that I was referring to the chip's Debug Interface mode,  and not the FW's build configuration. So as long as you are debugging the application, you will only be able to enter what's called "Emulated System OFF mode". This is why sd_power_system_off() will return with an error instead of actually going to sleep if you try to debug the app.