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.

[Hung Bui]

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. 

[Sebastien DRI]

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

[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. 

[Sebastien DRI]

Hi folks,

Sorry having played dead for so long.

So, I still have the app_error_fault_handler with PC=0x1505C even if SysTick is deactivated and I run from now on a 1ms RTC based.

It occurs randomly and provoke a reset sequence.

I have also removed the softdevice flash write.

Is there a way to find the root cause of this overstay issue?

Best regards

[Hung Bui]

Hi Sebastien, 

Sorry for delayed reply. I think what we should do next is to try reproducing the problem here so we can investigate. 

Could you try to either strip down your application to minimize it but still can reproduce the issue ? 

Or preferably re-create the problem on a SDK's example ? 

This will make it easier to narrow down the root cause. 

Please make sure you are using a production level chip, not an engineering revision.