app_error_fault_handler with PC=0x1505C

Hi Folks,

Any fix concerning this issue cause we are facing the same problem randomly at the same address offset (See Screenshot below).

I saw it could be a overstay issue : RE: Application fault in SoftDevice 

Is this issue inherent to the 7.0.1 version?

As you can see, it is located at 0x1505C and a fault ID of 1 (and info of 0) and the instruction refers to a call to "svc 255" (supervisor call  but unknow id).

I use SDK 16.0.0 with softdevice 7.0.1

I must add that this error occurs randomly in our functionning more precisely when uploading data to the target (which is a peripheral configured in long range mode) from a central so communication is stressed a bit.

  • Hi Sebastien, 
    As you already found from the other case, it may related to overstaying in REM event. 
    Do you use time slot in your application ? Or do you do any multiprotocol ? This should not happen if you only use the softdevice and BLE. 
    If you don't use any timeslot or multiprotocol, we then need to look at the timing of the oscillator. There could be an issue with it. What's the LFCLK source you are having ? 

    How often do you see the issue  ?
    Can you try to reproduce the issue on a DK. It should have no problem with the oscillators. 

  • Hi Hung,

    Thank you for your answer.

    I only use BLE and softdevice like the Nus example in the sdk 16.0.0. No timeslot and multiprotocol as well.

    We use a quartz oscillators for LFCLK and HFCLK .

    Concerning the LFCLK, we configure on XTAL, here is the sdk_config.h used:


    The issue comes sometimes, at an undetermined moment.


Reply Children
  • Hi Sebastien, 
    It's quite strange that such issue happens without timeslot or multiprotocol. 
    Do you do anything in a high priority interrupt handler ? 
    Could you tell a little bit more on the occur rate of the issue, like after you testing for several hours ? Or just matter of minutes/seconds ? How often it is, how many times you experienced it ? 

    If you test with our examples , do you see the same problem ?
    Is it possible to run the your firmware on our DK ? 
    Could you provide more information about the crystal you use ? Please try using the RC 32kHz for comparison. 

  • Hi Hung,

    I just have IRQ5 used for systick but nothing else above.Is it any issue in using irq 5 to trigger a systick interrupt?

    The rate of the issue is very low , however we experienced it more often when we stress the BLE communication link.

    I shall add that we are performing sd_flash_write operation so maybe is there a timeslot issue while performing those operations.

    I try to decrease the Systick interrupt to 6 and to use the RC oscillator.

    Here is the 32KHz Crystal datasheet used in our design:

    Thank you in advance for your support

  • Thanks for the information. 

    You mentioned SYSTICK. Could you tell a little bit more about that  ? Do you use any RTOS ? 
    How often do you trigger SYSTICK ? For normal application we suggest to use app_timer (RTC) instead of SYSTICK as it draws less current. 
    Where do you call sd_flash_write()  ? 

    From what you described interrupt priority of level 5 shouldn't cause any trouble with the softdevice. 

  • SYSTICK is triggered every 1ms to schedule task.

    This scheduler is simply made by ourselves by launch series of routines when Systick is raised.

    No RTOS in our case.

    sd_flash_write is called inside our application after softdevice was enable.

    In the past, I had one issue because I wanted to perform BLE  name to connect  modification (BLE central modif + flash name modification) without resetting the target and I got a NRF_EVT_FLASH_OPERATION_ERROR.

    This issue was solved by changing the scan timing to:

    /* Determines scan interval in units of 0.625 millisecond. */
    #define SCAN_INTERVAL 350U
    /* Determines scan window in units of 0.625 millisecond. */
    #define SCAN_WINDOW 50U
    /* Timout when scanning. 0x0000 disables timeout. */
    #define SCAN_TIMEOUT 2000U

    So it give more time to the flash slot time to work.

    The advertising is set to 20ms of adv interval.

  • I wrote another question to a previous thread related to IC revision.

    We are using a softdevice 7.0.1 (sdk 16.0.0) onto a nrf52840 rev C version of which compatibility is not ensured according to your compatibilty matrix. However we plan to use a rev 2 IC version if our future design.

    Has it an importance for my concern?