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.

Parents
  • 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:

    7450.sdk_config.h

    The issue comes sometimes, at an undetermined moment.

    Regards

  • 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:

    https://www.microcrystal.com/fileadmin/Media/Products/32kHz/Datasheet/CC8V-T1A_Medical.pdf

    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. 

Reply
  • 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. 

Children
  • 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?

  • Hi Sebastien, 
    I assume by rev C you meant the engineering C version ? If it is we would strongly suggest to continue your development on the latest version (rev 3).  You may need to move to SDK v17 if you use rev 3. I don't know about the availability of rev 2 IC, out Sales should know more about this. 


    Regarding flash operation and scanning, if you have a look here , you can find that if the flash operation is blocked for a few time it will get higher priority (same priority as scanning) and will not be pre-empted by the scanner. So I'm not so sure why you receive NRF_EVT_FLASH_OPERATION_ERROR.
    If you use Systick to schedule task, I would suggest to consider using RTC (app timer) . As I mentioned , they have better power consumption and is used in most of our examples. 

  • Hi Hung,

    Flash event error is related to this thread  NVMC timing: Flash access blocked during low latency BT communication? .

    I will try to use the RTC for generating my 1ms period clock.

    I will also get back to you after some testing.

  • Hi Sebastien, 

    On some corner cases flash operation may timeout. As far as I know , usually that happens when you have long scan interval and you may have queued several flash operations causing a timeout.

    The case was from 7 years ago and the scheduler may have changed. But I agree that if you have many flash activity and scan it may cause a flash timeout occasionally. 

Related