This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SD raises AppError with no details occasionally

We're getting this strange AppError that is supposedly coming from the SD (considering the PC is correct)

App error: id: 0x00000001, pc: 0x0001505C, code: 0x00000715

I do not currently have an application that would reproduce the problem, nor do I have any special steps to reproduce the problem since there is no special pattern on when the app error happens.

The device is scanning BLE beacons 99.9% of the time. Disabling the scanning definitely helps, the error doesn't happen when BLE is off.
We're using FreeRTOS, SD (s140_nrf52_7.0.1_softdevice) and SDK v16.0.0.

My colleague was able to trace through the Cortex-M core registers, the Radio (BLE) interrupt is active when the app error occurs. 3 other interrupts are also pending at that time: SWI5 (software interrupt, no direct code references to it, so assumed to be used internally by softdevice), GPIOE and RTC1.

Parents
  • Hi Carl,

    We're trying to see if we can use one of the example applications to demonstrate the problem. I'll keep you posted.

    On the "occasionally" part of the question - It happens almost randomly. Just out of the blue the device throws the app error and reboots.

    It is a custom board and I do have access to the debugger. I'm using VScode to debug and when I get the app error this is the stack trace with #define DEBUG enabled.

    Re: softdevice activity: yup, we only do the scanning. On every scan there is a minimal amount of processing. On every BLE report, we only check if the MAC address confirms a filter (`memcmp` the first few bytes). Then the data is inserted into a queue using FreeRTOS xQueueSendToBack with xTicksToWait==0 so if the queue is full the method will just return.

    Re: buffer overflow - I tried to analyze if we have any buffer overflows, but there isn't a single buffer that we use that can overflow during the report processing.

  • The logger backend is RTT and we use DEBUG as the default severity level.

    I was looking for the pointer on where the `APP_ERROR_CHECK` is getting called from, but unfortunately it's always seems to be coming from SD area (0-0x27000) - based on the call stack when the debugger stops inside of the app error handler

  • Oleg Z said:
    I was looking for the pointer on where the `APP_ERROR_CHECK` is getting called from, but unfortunately it's always seems to be coming from SD area (0-0x27000) - based on the call stack when the debugger stops inside of the app error handler

    The application error handler is only handling application layer errors, so it should not be triggered by the SoftDevice directly.

    The error address, 0x00000001 in the SoftDevice base translates to NRF_ERROR_SVC_HANDLER_MISSING.

    You will get this error if you have not enabled the SoftDevice (using sd_ble_enable) or if the headers included for the SoftDevice are not the correct headers for the particular SoftDevice you are using.

    There may also be other causes for the error. If it is none of the above, please share the code snippets that are relevant for your scanning and SoftDevice configuration, so I may take a look and see if I can spot something that might cause this.
    Please use the Insert -> Code option when sharing code here on the forum, as that increases its readability greatly! :)

    Looking forward to resolving this issue together!

    Best regards,
    Karl

Reply
  • Oleg Z said:
    I was looking for the pointer on where the `APP_ERROR_CHECK` is getting called from, but unfortunately it's always seems to be coming from SD area (0-0x27000) - based on the call stack when the debugger stops inside of the app error handler

    The application error handler is only handling application layer errors, so it should not be triggered by the SoftDevice directly.

    The error address, 0x00000001 in the SoftDevice base translates to NRF_ERROR_SVC_HANDLER_MISSING.

    You will get this error if you have not enabled the SoftDevice (using sd_ble_enable) or if the headers included for the SoftDevice are not the correct headers for the particular SoftDevice you are using.

    There may also be other causes for the error. If it is none of the above, please share the code snippets that are relevant for your scanning and SoftDevice configuration, so I may take a look and see if I can spot something that might cause this.
    Please use the Insert -> Code option when sharing code here on the forum, as that increases its readability greatly! :)

    Looking forward to resolving this issue together!

    Best regards,
    Karl

Children
No Data
Related