app_error_fault_handler with PC=0x1505C

[Sebastien DRI]

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.

[Sebastien DRI]

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.

[Sebastien DRI]

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?

[Hung Bui]

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. 

[Sebastien DRI]

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.

[Hung Bui]

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.