app_error_fault_handler with PC=0x1505C

RE: app_error_fault_handler with PC=0x1505C

Hung Bui — Mon, 16 Oct 2023 07:24:05 GMT

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.

RE: app_error_fault_handler with PC=0x1505C

Sebastien DRI — Thu, 12 Oct 2023 15:56:47 GMT

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

RE: app_error_fault_handler with PC=0x1505C

Hung Bui — Fri, 24 Mar 2023 13:09:28 GMT

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.

RE: app_error_fault_handler with PC=0x1505C

Sebastien DRI — Fri, 24 Mar 2023 10:36:19 GMT

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.

RE: app_error_fault_handler with PC=0x1505C

Hung Bui — Fri, 24 Mar 2023 09:21:22 GMT

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.

RE: app_error_fault_handler with PC=0x1505C

Sebastien DRI — Thu, 23 Mar 2023 14:53:19 GMT

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?

RE: app_error_fault_handler with PC=0x1505C

Sebastien DRI — Thu, 23 Mar 2023 14:47:17 GMT

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.

RE: app_error_fault_handler with PC=0x1505C

Hung Bui — Thu, 23 Mar 2023 14:33:21 GMT

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.

RE: app_error_fault_handler with PC=0x1505C

Sebastien DRI — Thu, 23 Mar 2023 14:16:44 GMT

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

RE: app_error_fault_handler with PC=0x1505C

Hung Bui — Tue, 21 Mar 2023 12:08:02 GMT

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.

RE: app_error_fault_handler with PC=0x1505C

Sebastien DRI — Sat, 18 Mar 2023 17:10:13 GMT

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:

devzone.nordicsemi.com/.../7450.sdk_5F00_config.h

The issue comes sometimes, at an undetermined moment.

Regards

RE: app_error_fault_handler with PC=0x1505C

Hung Bui — Thu, 16 Mar 2023 13:51:00 GMT

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.