[nrf52840][zephyr] SPI Access in GPIOTE interrupt causes a kernel panic

RE: [nrf52840][zephyr] SPI Access in GPIOTE interrupt causes a kernel panic

0xGael — Wed, 16 Jul 2025 08:16:50 GMT

I reply to myself to close the issue :

I solved the issue by reworking my driver to be RTOS compatible:

* when the driver needs to wait for an interrupt on a pin, in the pin interrupt callback I call an API from my driver to handle the interrupt

* in the previous API I do the minimal work :

* disable pin interrupt (to avoid being retriggered)

gpio_pin_interrupt_configure_dt()

* then I raise an RTOS event to notify a task which will handle others driver's actions:

k_event_post()

* In the driver context, when driver needs to wait for the pin interrupt :

* it clears the event mask to wait for :

k_event_clear()

* then it waits for the event :

k_event_wait()

* When the event is raised (because the pin has interrupted), I call a function to handle the remaining actions (read SPI bus) :

spi_transceive()

RE: [nrf52840][zephyr] SPI Access in GPIOTE interrupt causes a kernel panic

Sigurd Hellesvik — Fri, 26 Jul 2024 12:58:22 GMT

Thanks for the context!

I found this https://github.com/zephyrproject-rtos/zephyr/issues/70915 and this https://github.com/zephyrproject-rtos/zephyr/issues/59116 which could maybe be related to a similar issue?

RE: [nrf52840][zephyr] SPI Access in GPIOTE interrupt causes a kernel panic

0xGael — Fri, 19 Jul 2024 15:10:36 GMT

Hi Sigurd,

Are you writing the driver as part of your project, or as part of Zephyr?
Are your writing a driver for an external sensor?

No. I'm integrating a driver (for an external sensor) into an application I'm writing. I don't try to integrate the driver in Zephyr.

The code of icm42605_trigger. is a good example for my case to asynchronize the processing of my gpio interrupt (in another thread), without modifying the code of the driver I'm integrating.

But I still don't understand why I have the crash in my initial implementation

RE: [nrf52840][zephyr] SPI Access in GPIOTE interrupt causes a kernel panic

Sigurd Hellesvik — Fri, 19 Jul 2024 13:08:28 GMT

Ah, you are talking about integrating a driver. (I missed that in my first read of the ticket)

Workqueue threads may not be the right solution, as you say.

Here are some questions for me to understand this a bit better:

Are you writing the driver as part of your project, or as part of Zephyr?
Are your writing a driver for an external sensor?

Maybe have a look at other Zephyr drivers for sensor, such as https://github.com/nrfconnect/sdk-zephyr/blob/v3.6.99-ncs2/drivers/sensor/tdk/icm42688/icm42688_spi.c
or
https://github.com/nrfconnect/sdk-zephyr/blob/v3.6.99-ncs2/drivers/sensor/tdk/icm42605/icm42605_trigger.c

Does these help?

RE: [nrf52840][zephyr] SPI Access in GPIOTE interrupt causes a kernel panic

0xGael — Thu, 18 Jul 2024 14:33:38 GMT

Hi Sigurd,

Are you working with interrupts from a ISR?

This is one of my point. The Zephyr API hides many thing so it's not easy to understand which peripheral and features are really used.

I defined my spi device as compatible = "nordic,nrf-spim"; in the overlay, so it uses easyDMA, so I suppose it uses interrupts.

Instead I recommend using a Workqueue thread?

What do you mean ? You mean use the workqueue thread instead of semaphore ?

I would like as much as possible to don't change the driver code. So I'd like to understand why I have the lock issue instead of changing the driver's code

PS : I started to read "nRF Connect SDK Intermediate"

RE: [nrf52840][zephyr] SPI Access in GPIOTE interrupt causes a kernel panic

Sigurd Hellesvik — Thu, 18 Jul 2024 11:07:05 GMT

Hi,

[quote user=""]Although I already used the nrf52840 on previous projects (nrfxlib), I'm a newbie using nRF Connect and ZephyrOS (I previously used RTOS).[/quote]

I recommend the Nordic Developer Academy as an excellent place to start learning the nRF Connect SDK.

For the issue:
Are you working with interrupts from a ISR?
Instead I recommend using a Workqueue thread? As its docs say:
". A workqueue is typically used by an ISR or a high-priority thread to offload non-urgent processing to a lower-priority thread so it does not impact time-sensitive processing."

Regards,
Sigurd Hellesvik