nrf5 SDK SVC #255 / 0xFF

RE: nrf5 SDK SVC #255 / 0xFF

Sigurd — Wed, 09 Oct 2024 11:19:12 GMT

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.

RE: nrf5 SDK SVC #255 / 0xFF

Arne_CV — Wed, 09 Oct 2024 11:00:30 GMT

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

RE: nrf5 SDK SVC #255 / 0xFF

Sigurd — Tue, 08 Oct 2024 19:50:45 GMT

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

RE: nrf5 SDK SVC #255 / 0xFF

Turbo J — Tue, 08 Oct 2024 12:25:58 GMT

The SVC number might be a "don't care" here, this value is not properly tracked in the ARMv7-M hardware registers. In case software wanted to use it, it has to read it from the calling code flash via the stacked PC pointer.

You are probably looking at an SD SVC call from either the app or the softdevice interrupt handler...