ERROR 1813 [Unknown error code] at KGJ`hóˆ@h:536871936 PC at: 0x0001505C

[Shreya J B]

Hi,

I am using the nRF52840 with nRF-SDK version 16.0.

At random intervals, I encounter the following error:

"[00:02:51.009,460] <error> app: ERROR 1813 [Unknown error code] at KGJ`hh:536871936 PC at: 0x0001505C".

This issue appears to be the same as one previously reported-here, but that ticket did not provide any helpful details.

Could you please explain under what conditions this error occurs? It would help me narrow down the source of the problem in my code.

Thank you,
Shreya

[Einar Thorsrud]

Hi,

Are you using the S140 SoftDevice? If so, the program counter (PC) at 0x0001505C is within the SoftDevice. 536871936 in hex is 0x20000400, which is a valid memory address in RAM (though that should not be the content here). Could it be that the application memory overlaps with the SoftDevice memory? Can you incrase the application RAM start address a bit and see if that makes a difference?

[Shreya J B]

Einar Thorsrud said:

Are you using the S140 SoftDevice?

yes.

Einar Thorsrud said:

Can you incrase the application RAM start address a bit and see if that makes a difference?

I increased the RAM start address from 0x20002AF8 to 0x20003000, but the error still occurs.

[Einar Thorsrud]

Hi,

I see. How often do the issue occur? Are you able to share a project that can reproduce it on a DK?

[Shreya J B]

Hi,

The occurrence of this issue is quite random. I’ve observed it within 48 hours when logging is enabled.
Even I’m not sure exactly when it gets reproduced, so it’s difficult to share a specific project state that triggers it.

[Einar Thorsrud]

Hi,

I would have expeced another error log with a SoftDevice assert, but the PC value match an assert in the SoftDevice, as described in this thread which seems an unlikely coincidence. Do you have much processing in interrupts, or long critical sections, or other activities that could block SoftDevice interrupts for a too long time?

[Shreya J B]

Hi,

You're right — the log we're seeing is different because we're using a custom app_fault_handler, which overrides the default SoftDevice fault message. Otherwise, it would have shown SOFTDEVICE: ASSERTION FAILED.

So far, I haven’t observed any extensive processing in our interrupt handlers. All application interrupts are set to priority 6, except for the watchdog IRQ, which is configured at priority 3. We’ve ensured that no critical sections or blocking code exist within ISRs that could interfere with SoftDevice timing.

The device enters a hang state after the SoftDevice assert and only recovers via watchdog reset.

Please let me know if there are any other areas we should specifically check.

[Einar Thorsrud]

Hi,

Tthe assert itself does not tell us anything about what caused it, other than that somehow the SoftDevice was not able to process an interrupt/event hon time. But it should be something that runs on a higher priority or that interrupts are disabaled (via critical sections). Can you double check that you don't have any other interrupts with higher priority (lower number) than 4?