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.

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

    That would be great, please let me know if you are able to reproduce it.

    Oleg Z said:
    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 hard to estimate, I see, thank you for clarifying.

    Oleg Z said:
    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.

    The app_error_fault_handler call makes me suspect that the issue is caused by a non-NRF_SUCCESS error code being passed to an APP_ERROR_CHECK. This is the most common case. With DEBUG defined in your preprocessor defined you should see a detailed error message (including the specific faulting error and the function who returned it) in the logger. Which logger backend and logging severity level are you using?

    Best regards,
    Karl 

Reply
  • Oleg Z said:
    We're trying to see if we can use one of the example applications to demonstrate the problem. I'll keep you posted.

    That would be great, please let me know if you are able to reproduce it.

    Oleg Z said:
    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 hard to estimate, I see, thank you for clarifying.

    Oleg Z said:
    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.

    The app_error_fault_handler call makes me suspect that the issue is caused by a non-NRF_SUCCESS error code being passed to an APP_ERROR_CHECK. This is the most common case. With DEBUG defined in your preprocessor defined you should see a detailed error message (including the specific faulting error and the function who returned it) in the logger. Which logger backend and logging severity level are you using?

    Best regards,
    Karl 

Children
No Data
Related