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,

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?

[Shreya J B]

HI,

I’ve checked the interrupt priorities in the project and noticed that in the SPI initialization code, the interrupt priority is explicitly set to 2 in non-blocking mode. Could this be the cause of the assert failure we’re seeing?

[Einar Thorsrud]

Hi,

I see. I would have been more sceptical to critical regions or priorities that are even higher (0). That said, it would be interesting to see if you are able to reproduce if you set the priority of the SPI interrupts to 6 as well?

[Shreya J B]

Einar Thorsrud said:

if you are able to reproduce if you set the priority of the SPI interrupts to 6 as well?

Sure, I will keep the test with SPI interrupt priority set to 6 and let you know the results.

[Shreya J B]

Hi,

The issue is still getting reproduced even after setting the SPI interrupt priorities to 6. We have configured the interrupt priorities to 6 in sdk_config.h and are no longer setting them explicitly. However, when I logged the IRQ priorities using NVIC_GetPriority(irq), I noticed that many IRQs still have different priorities. Am I checking this incorrectly?

I’ve attached the logged IRQ priorities for your reference.

00> [00:04:26.582,336] <info> app: Logging all IRQ priorities:
00> [00:04:26.582,458] <info> app: IRQ 0 (POWER_CLOCK_IRQn): priority 4
00> [00:04:26.582,580] <info> app: IRQ 1 (RADIO_IRQn): priority 0
00> [00:04:26.582,702] <info> app: IRQ 2 (UARTE0_UART0_IRQn): priority 0
00> [00:04:26.582,885] <info> app: IRQ 3 (SPIM0_SPIS0_TWIM0_TWIS0_SPI0_TWI0_IRQn): priority 0
00> [00:04:26.583,007] <info> app: IRQ 4 (SPIM1_SPIS1_TWIM1_TWIS1_SPI1_TWI1_IRQn): priority 6
00> [00:04:26.583,190] <info> app: IRQ 5 (NFCT_IRQn): priority 0
00> [00:04:26.583,312] <info> app: IRQ 6 (GPIOTE_IRQn): priority 6
00> [00:04:26.584,411] <info> app: IRQ 7 (SAADC_IRQn): priority 6
00> [00:04:26.584,594] <info> app: IRQ 8 (TIMER0_IRQn): priority 0
00> [00:04:26.586,730] <info> app: IRQ 9 (TIMER1_IRQn): priority 0
00> [00:04:26.586,853] <info> app: IRQ 10 (TIMER2_IRQn): priority 0
00> [00:04:26.586,975] <info> app: IRQ 11 (RTC0_IRQn): priority 0
00> [00:04:26.587,097] <info> app: IRQ 12 (TEMP_IRQn): priority 0
00> [00:04:26.587,219] <info> app: IRQ 13 (RNG_IRQn): priority 4
00> [00:04:26.587,402] <info> app: IRQ 14 (ECB_IRQn): priority 4
00> [00:04:26.588,500] <info> app: IRQ 15 (CCM_AAR_IRQn): priority 4
00> [00:04:26.588,623] <info> app: IRQ 16 (WDT_IRQn): priority 0
00> [00:04:26.590,759] <info> app: IRQ 17 (RTC1_IRQn): priority 6
00> [00:04:26.590,942] <info> app: IRQ 18 (QDEC_IRQn): priority 0
00> [00:04:26.591,064] <info> app: IRQ 19 (COMP_LPCOMP_IRQn): priority 0
00> [00:04:26.591,186] <info> app: IRQ 20 (SWI0_EGU0_IRQn): priority 0
00> [00:04:26.591,308] <info> app: IRQ 21 (SWI1_EGU1_IRQn): priority 6
00> [00:04:26.592,468] <info> app: IRQ 22 (SWI2_EGU2_IRQn): priority 6
00> [00:04:26.592,590] <info> app: IRQ 23 (SWI3_EGU3_IRQn): priority 0
00> [00:04:26.594,726] <info> app: IRQ 24 (SWI4_EGU4_IRQn): priority 0
00> [00:04:26.594,909] <info> app: IRQ 25 (SWI5_EGU5_IRQn): priority 4
00> [00:04:26.595,031] <info> app: IRQ 26 (TIMER3_IRQn): priority 0
00> [00:04:26.595,153] <info> app: IRQ 27 (TIMER4_IRQn): priority 0
00> [00:04:26.595,275] <info> app: IRQ 28 (PWM0_IRQn): priority 0
00> [00:04:26.596,435] <info> app: IRQ 29 (PDM_IRQn): priority 0
00> [00:04:26.596,557] <info> app: IRQ 30 (Reserved (30)): priority 0
00> [00:04:26.599,853] <info> app: IRQ 32 (MWU_IRQn): priority 1
00> [00:04:26.599,975] <info> app: IRQ 33 (PWM1_IRQn): priority 0
00> [00:04:26.600,097] <info> app: IRQ 34 (PWM2_IRQn): priority 0
00> [00:04:26.600,219] <info> app: IRQ 35 (SPIM2_SPIS2_SPI2_IRQn): priority 0
00> [00:04:26.600,402] <info> app: IRQ 36 (RTC2_IRQn): priority 6
00> [00:04:26.600,524] <info> app: IRQ 37 (I2S_IRQn): priority 0
00> [00:04:26.600,646] <info> app: IRQ 38 (FPU_IRQn): priority 0
00> [00:04:26.600,769] <info> app: IRQ 39 (USBD_IRQn): priority 0
00> [00:04:26.602,905] <info> app: IRQ 40 (UARTE1_IRQn): priority 0
00> [00:04:26.603,027] <info> app: IRQ 41 (QSPI_IRQn): priority 0
00> [00:04:26.603,210] <info> app: IRQ 42 (CRYPTOCELL_IRQn): priority 0
00> [00:04:26.603,332] <info> app: IRQ 43 (Reserved (43)): priority 0
00> [00:04:26.604,492] <info> app: IRQ 44 (Reserved (44)): priority 0
00> [00:04:26.604,614] <info> app: IRQ 45 (PWM3_IRQn): priority 0
00> [00:04:26.604,736] <info> app: IRQ 46 (Reserved (46)): priority 0
00> [00:04:26.606,872] <info> app: IRQ 47 (SPIM3_IRQn): priority 0

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