LL_ASSERT in event_common_prepare in Zephyr v1.13

[PhilippFinke]

Hey,

I'm currently running into a LL_ASSERT in event_common_prepare. I'm running Zephyr v1.13 on a custom nrf52840 board acting as a BLE peripheral. It seems that this issue already occurred in a later version of Zephyr (see #3287).

Can anybody help with this issue?

[cvinayak]

Please review your application for any large interrupt latencies introduced, do you disable interrupts or have interrupt service routines at highest priority level?

[PhilippFinke]

I'm using TIMER2 interrupt with priority level 7. I'm not using irq_lock in my application.

[cvinayak]

@PhilippFinke if I understand right, priority level 7 rolls over to being level 0, as in nRF52840 the levels are offset by 1, refer to https://github.com/zephyrproject-rtos/zephyr/blob/master/include/arch/arm/cortex_m/exc.h#L37

@carlescufi correct me please.

[PhilippFinke]

CONFIG_ZERO_LATENCY_IRQS is not set in my case.

[carlescufi]

I'm using TIMER2 interrupt with priority level 7. I'm not using irq_lock in my application.

Can you share a code snippet on how you are using it?

Also please give us more information about the assert itself. File and line number if possible.

[PhilippFinke]

I get the LL_ASSERT in file ctrl.c line 5649. Here's my code that initializes and handles the timer interrupts.
drvLedMatrix_timer.txt

[carlescufi]

So you are using this code:

      IRQ_CONNECT(NRF5_IRQ_TIMER2_IRQn, NRFX_TIMER_DEFAULT_CONFIG_IRQ_PRIORITY, timerIsr, NULL, 0);
      irq_enable(NRF5_IRQ_TIMER2_IRQn);

      nrfx_timer_config_t sConfig = { .frequency          = NRF_TIMER_FREQ_1MHz,
                                      .mode               = NRF_TIMER_MODE_TIMER,
                                      .bit_width          = NRF_TIMER_BIT_WIDTH_32,
                                      .interrupt_priority = NRFX_TIMER_DEFAULT_CONFIG_IRQ_PRIORITY,
                                      .p_context          = NULL
                                    };

      if (NRFX_SUCCESS == nrfx_timer_init((nrfx_timer_t*)&drvLedMatrix_timer_sInstance, &sConfig, timerHandler))

This is a priority of 7 as you mentioned, so it seems unlikely that this would be the issue.

@cvinayak is there another cause for hitting this assert:

zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c

Line 5649 in d62e861

LL_ASSERT(!retval);

other than added latency?

[carlescufi]

@PhilippFinke could you please try out this PR which contains a long list of fixes for 1.13?

#12135

EDIT: Or you could of course try with current master, but then you might need to change and adapt some of your code.

[carlescufi]

@PhilippFinke the priority needs to be 0-6 and not 7, because Zephyr reserves a priority for itself. Can you try with 6?

[PhilippFinke]

Happy new year everybody!

@carlescufi I'll give it a try.

[PhilippFinke]

The issue persists even if I deactivate the timer interrupt.

[carlescufi]

@PhilippFinke so this might be unrelated to the timer you are using then. Could you try using this PR: #12135 ?

[PhilippFinke]

@carlescufi how do I apply this patch?

[carlescufi]

@PhilippFinke easiest way is probably to merge the branch into your own. Just add a remote with the correct URL (https://github.com/sjanc/zephyr) and then merge sjanc/1131 into your own branch. There are other options, like using git pr from the git-extras package.

[PhilippFinke]

@carlescufi I tried the patch, but the issue still persists. It seems that the issue only occurs when I run into a breakpoint or stop while debugging, but I'm pretty sure that wasn't always the case.

[carlescufi]

If you run into a breakpoint or you debug then it is a non-issue: the timers will keep running and the code does not execute, which means that the LL will soon detect it has run out of time to execute in hard real-time and will assert.

[PhilippFinke]

This is an explanation. Could we keep this issue still open? I'm remembering facing this problem in other situations, too. I want to check this first.

[carlescufi]

Sure, no worries. It's marked as a question so I will leave it open for you to confirm if that is indeed the issue.

[ioannisg]

@PhilippFinke please, re-open, if needed, to continue discussion