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,

This list looks sensible. Some are set to 1 and 4, and those are used by the SoftDevice. Regarding thouse with priority 0 it is difficult to say. To be sure, you could also check with NVIC_GetEnableIRQ() to see if interrupts are enabled? (or do you see any with priority 0 that you use dierectly, and not via the SoftDevice)?

If this is all good, maybe we need to look elsewhere. I see interested in configurations that affect scheduling, such as NRF_SDH_BLE_GAP_EVENT_LENGTH.

[Shreya J B]

Hi,

Thanks for your input. I checked the enabled IRQs using NVIC_GetEnableIRQ(), and all enabled interrupts appear correctly configured for our application. So, from the IRQ priority perspective, everything seems fine.

Could you please help me debug further? Regarding NRF_SDH_BLE_GAP_EVENT_LENGTH Currently, it is set to 7.5 ms.
 Our connection parameters are as follows:

#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(30, UNIT_1_25_MS)         
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(40, UNIT_1_25_MS)          
#define SLAVE_LATENCY                   5                                           
#define CONN_SUP_TIMEOUT                MSEC_TO_UNITS(10000, UNIT_10_MS)

What should I check or adjust related to NRF_SDH_BLE_GAP_EVENT_LENGTH or other BLE scheduling parameters?

[Einar Thorsrud]

Hi,

I see.

Can you try increasing NRF_SDH_BLE_GAP_EVENT_LENGTH (for instance doubling it) as an experiment? Also, what is the LF clock source configuration? Does configuring a lower accuracy (higher ppm) value make a difference?

[Shreya J B]

Einar Thorsrud said:

Can you try increasing NRF_SDH_BLE_GAP_EVENT_LENGTH (for instance doubling it) as an experiment?

Sure, I will try.

Einar Thorsrud said:

what is the LF clock source configuration?

We are currently using:

NRF_SDH_CLOCK_LF_ACCURACY          NRF_CLOCK_LF_ACCURACY_20_PPM
NRF_SDH_CLOCK_LF_SRC               NRF_CLOCK_LF_SRC_XTAL
NRF_SDH_CLOCK_LF_RC_CTIV           0
NRF_SDH_CLOCK_LF_RC_TEMP_CTIV      0

As an experiment, I’ll change the accuracy to NRF_CLOCK_LF_ACCURACY_100_PPM and observe if it makes any difference.
I’ll share the results once I’ve tested this.

[Shreya J B]

Hi,
I increased the NRF_SDH_BLE_GAP_EVENT_LENGTH from 6 to 12. After this change, I observed an assertion after 10 days.

Previously, I used to get CPU lockup resets more frequently, but after this change, they have reduced. Could this change have contributed to the improvement?

[Einar Thorsrud]

Hi,

That is an interesting obeservation, and it could be related, as this will affect the schedulign in the SoftDevice (reserving more time for each connection event). Could you also try to incrase the PPM configuration for the LF clock to (say) NRF_CLOCK_LF_ACCURACY_250_PPM and see if that also gives an imrovement (both alone and combined with longer event length)?

Edit: While I do not understand the root cause, another potential workaround is to increase NRF_SDH_BLE_GAP_DATA_LENGTH in sdk_config.h to add more margin that way.

[Shreya J B]

Hi,

Einar Thorsrud said:

Could you also try to incrase the PPM configuration for the LF clock to (say) NRF_CLOCK_LF_ACCURACY_250_PPM

Sure, I’ll run the test with the LF clock accuracy set to NRF_CLOCK_LF_ACCURACY_250_PPM  and let you know the results.

Regarding the NRF_SDH_BLE_GAP_DATA_LENGTH, we’ve already configured it to the maximum value, which is 251.

[Shreya J B]

Hi,

I tested the following configurations:

• Only increased the LF clock PPM (lower accuracy): The issue reoccurred after 6 days.

• Increased both the PPM and the event length: The issue reoccurred after 10 days.

• Increased only the event length (logging disabled): The system has been running for 18 days without any reset.

Could this issue be occurring only when RTT logging is enabled?

[Edvin]

Hello,

Einar is out of office.

Shreya J B said:

Could this issue be occurring only when RTT logging is enabled?

I am not sure. Do you see it if you disable logging? 

Were you able to reproduce this issue on a DK? This way, it would be easier for our SoftDevice team to debug the issue. 

Best regards,

Edvin

[Shreya J B]

Hi,

Thanks for the response,

Edvin said:

I am not sure. Do you see it if you disable logging? 

When logging was disabled, the issue did not occur for 25 days. So, I suspect that the issue might be related to logging. However, I'm not sure whether this assumption is correct.

Edvin said:

Were you able to reproduce this issue on a DK?

We haven't tried reproducing the issue on a DK, as our custom board has some sensors integrated. The issue occurs randomly during communication with these sensors.