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

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

Vidar Berg — Tue, 25 Jan 2022 21:02:34 GMT

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.

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

viktor.kz — Tue, 25 Jan 2022 17:03:21 GMT

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).

[quote userid="4240" url="~/f/nordic-q-a/83799/spurious-restarts-on-nrf52832-with-ble_app_uart-example-if-no-ble-device-connected/348456#348456"]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.[/quote]

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.

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

Vidar Berg — Tue, 25 Jan 2022 08:20:51 GMT

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

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

viktor.kz — Mon, 24 Jan 2022 19:42:50 GMT

[quote userid="4240" url="~/f/nordic-q-a/83799/spurious-restarts-on-nrf52832-with-ble_app_uart-example-if-no-ble-device-connected/349258#349258"]Can you confirm that app_error_fault_handler() is only defined in app_error_weak.c and not redefined elsewhere in your project[/quote]

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.

[quote userid="4240" url="~/f/nordic-q-a/83799/spurious-restarts-on-nrf52832-with-ble_app_uart-example-if-no-ble-device-connected/349258#349258"]Can you search through the project for "NVIC_SystemReset()" and see if it may be called anywhere else in your code?[/quote]

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

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

Vidar Berg — Mon, 24 Jan 2022 12:57:52 GMT

Hi Viktor,

[quote user="viktor.kz"]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.[/quote]

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.

[quote user="viktor.kz"]I've tried to break on the app_error_handler or app_error_fault_handler, but neither breakpoint is hit.[/quote]

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?

[quote user="viktor.kz"]Here is how it looks like when I use Debug configuration and also enable debug messages via RTT, still no crashlog:[/quote]

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

Best regards,

Vidar

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

viktor.kz — Sat, 22 Jan 2022 19:28:27 GMT

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.

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

[quote userid="4240" url="~/f/nordic-q-a/83799/spurious-restarts-on-nrf52832-with-ble_app_uart-example-if-no-ble-device-connected/348456#348456"]Note that you can use the "Debug" build configuration to get more error information from the fault handler (crashlog is printed out on RTT):[/quote]

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

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

Vidar Berg — Wed, 19 Jan 2022 10:07:06 GMT

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