Getting invalid spinlock errors. Too high IRQ priority or calling ISR_DIRECT_FOOTER too early?

[bofh69]

I'm using Nordic's NCS v2.5.2 version of Zephyr with nRF52840 (cortex M4).

I'm trying to wake up a thread from other threads as well as from ISRs. For this I've tried a couple of things, and they sooner or later end up with an error:

ASSERTION FAIL [z_spin_lock_valid(l)] @ WEST_TOPDIR/zephyr/include/zephyr/spinlock.h:114
	Invalid spinlock

The backtrace is:

#1  0x000171bc in z_spinlock_validate_pre (l=0x200020a8 <sched_spinlock>)
    at zephyr/include/zephyr/spinlock.h:114
#2  k_spin_lock (l=0x200020a8 <sched_spinlock>)
    at zephyr/include/zephyr/spinlock.h:171
#3  z_unpend_first_thread (
    wait_q=wait_q@entry=0x2000059c <my_sem>)
    at zephyr/kernel/sched.c:898
#4  0x000167ec in z_impl_k_sem_give (sem=0x2000059c <my_sem>)
    at zephyr/kernel/sem.c:96
...

which is called from the highest priority ISR.

In this case I'm using a semaphore, but I've gotten the same error when posting to a work queue, or when using many semaphores and k_poll together with irq_lock/unlock around the k_sem_take call.

From what I can see from the documentation, it should be possible to call k_sem_give and k_work_schedule from ISRs.

There are four ISRs involved. Three I have control over and set up with IRQ_DIRECT_CONNECT/ISR_DIRECT_DECLARE, the forth I don't know how it is created, it is inside a binary library.

Since the k_sem_give is the only Zephyr function being called from all four ISRs, I'm calling it like this:

if (!sem_given) {
    sem_given = 1;
    barrier_dsync_fence_full();
    ISR_DIRECT_HEADER();
    k_sem_give(&my_sem);
    ISR_DIRECT_FOOTER(1);
}

and I clear sem_given after sem_take in my thread. So hopefully this only causes it to be called from one of the ISRs until it has been handled by the thread.

The ISR I don't have control over is also the one running at the highest priority and it seems to always be in that ISR that we get the error above.

With FreeRTOS we had to trigger a lower priority SWI ISR to wake up the thread. When I did the same here, I no longer get the error, but I rather not do that because we don't have so many SWIs left.

Is the problem caused by me calling ISR_DIRECT_FOOTER(1) down in the call chain and not at the end of the ISR? Is it the same problem as in FreeRTOS, we call into Zephyr from an ISR at a too high priority so the scheduler is interrupted at the wrong time?
Something else?

[willdean]

Did you get anywhere with this? I have tried using a k_pipe from a direct ISR and had semaphore errors, which I thought were down to problems with k_pipe, but I am seeing the same problem with k_event.

Is there perhaps some alternative to direct ISRs which gives decent interrupt latency but allows kernel primitives to be used?

[bofh69]

A colleague took over this. I think we ended up having to signal a lower priority SWI which signals the threads. If I remember correctly the scheduler wasn't protected from being called into from a higher prio interrupt handler.