nrf5 SDK SVC #255 / 0xFF

[Arne_CV]

Hello all,

I ported an old nrf5 application from SDK 12.3 to SDK 17.1. It uses S112 7.3.0 and FreeRTOS. Unfortunately I am getting time variant softdevice hard faults at 0xA60. ETM debugging shows that the fault is triggered by at least two different places in the SD code, but always is SVC #255 the last instruction before the fault.

According to the SDS, it is the SVC is used by the Softdevice, but I was unable to find its purpose in the documentation and header files.

Does anyone how, what SVC #255 does? It is some kind of reset / error handler?

I hope it might point me to the root cause of crashes (memory issues, time constraints etc.)

Many thanks in advance!

Arne

[Sigurd]

Hi!

0x00000A60 is the hardfault exception handler inside the MBR. It's normally forwarded to the main application, but will get trapped if breakpoint on hardfault is enabled in SES.
You can disable it like this:

To debug hardfaults, add the HardFault handling library to your project

Add these to your projects:

$(SDK_ROOT)/components/libraries/hardfault/hardfault_implementation.c 
$(SDK_ROOT)/components/libraries/hardfault/nrf52/handler/hardfault_handler_gcc.c  (variant here depends on your toolchain)

And set HARDFAULT_HANDLER_ENABLED to 1 in sdk_config.h, and add DEBUG_NRF in your preprocessor definitions

[Arne_CV]

Hi,

I can see that the SVC is made during handling of IRQ 1 (RADIO). app_error_fault_handler() gets called with id = 1 (NRF_ERROR_SVC_HANDLER_MISSING). Any suggestions where it might come from? missing headers? Damaged vector table? 

Most parts of my application are working fine (SD init, BLE advertising, connect/disconnect), but sometimes this error occurs. So I guess that most SD SVCs are working fine 

[Sigurd]

Place a breakpoint in the app_error_fault_handler, and take a look at the callstack why it was called. It could actually be because of UART overrun, see this page:  "ble_app_uart" , https://docs.nordicsemi.com/bundle/ps_nrf52832/page/uarte.html#d955e7425

You should also look at the pc and info field the app_error_fault_handler() was called with.