Hello DevZone!
I am using a nrf5340 with the nrf Connect SDK v2.6.0. I have been running into an issue that has come up a few times on separate occasions. Basically, for no apparent reason, my GPIO handler sometimes decides to either not want to simply run, or the Zephyr scheduler does not context switch to a task based on the ISR unblocking it (with a semaphore, work submission, etc) unless I open the RTT logger output. I wish I could narrow it down to whether or not it is an issue with the ISR itself not running or a scheduling issue, but I am unable to because I can't open the RTT logger to tell me whether or not the ISR is running or else the issue will go away and can't observe it. I was hoping someone more knowledgeable with how Zephyr interrupts and scheduling works could give some ideas.
Occasion 1:
I have an application that does a bunch of I2C writes that must be done with a device that are synchronized with GPIO interrupts that give a semaphore to the thread making the I2C writes. The flow goes: thread writes I2C command to device, wait on semaphore, device soon thereafter drives GPIO IRQ pin high to indicate data is ready to be read, GPIO ISR for the IRQ pin gives the semaphore, thread is unblocked by taking the semaphore and continues with the next I2C read/write.
For this case, the GPIO interrupt is setup with Zephyr's GPIO driver by configuring the pin as an input that interrupts on a rising edge and has a Zephyr GPIO callback registered with the function that gives the semaphore. The relevant issue here is on the first I2C/GPIO semaphore transaction that the thread waits on, the thread is never unblocked by the semaphore even after confirming that the GPIO pin is driven high during the period of waiting. After the timeout for the semaphore runs out, the scheduler context switches to the thread, sees the semaphore hasn't been given error and aborts the rest of the I2C transactions. If I reset my code and run the same exact transaction but with the RTT logger output opened this time, the transaction completes perfectly and is properly unblocked by the semaphore and continues with the rest of the necessary I2C transactions. Please note that putting the main thread (separate from the thread running the I2C transactions) in an infinite while loop of just k_msleep(1) also fixes the issue as well.
Again, I do not know if the Zephyr scheduler is somehow refusing to context switch to the thread that is waiting on the semaphore or the GPIO ISR is simply not running in the first place which is clearly resolved when there is a higher priority thread sleeping/waking in the background. It's not feasible for my application to have main running k_msleep(1) forever as well as constantly have the RTT logger output open, so the root issue must be fixed. I am also aware of using IRQ_CONNECT vs. IRQ_DIRECT_CONNECT to invoke the scheduler or not whenever the ISR runs. I must admit, the issue certainly feels like it is because the ISR may be configured with IRQ_DIRECT_CONNECT and not invoking the scheduler, but I can confirm that I use the Zephyr GPIO driver to configure the interrupt which uses IRQ_CONNECT. I do not use IRQ_CONNECT/DIRECT_CONNECT anywhere else besides the Zephyr driver.
Occasion 2:
Separately on a more recent occasion, I am running into very similar behavior for a different part of the application. This application is different in that it calls the nrfx gpiote driver itself without using the Zephyr GPIO driver in order to configure the GPIO interrupt. In short, a GPIO pin has a nrfx gpiote interrupt configured to run the given handler for every rising edge event and is hooked up to a circuit that is generating a rising edge at a relatively high rate. The given ISR that runs upon the configured rising edge event submits work items that make it apparent that the interrupt is working correctly. However, similarly to the first occasion, the work items do not run unless I have the RTT logger output open. The work items are not running either because the scheduler is not running them or the GPIO interrupt isn't running in the first place for some reason.
I must admit that I do not completely understand how the GPIO ISR is configured with the nrfx gpiote driver in this occasion. From my understanding, the nrfx gpiote driver defines its own handler which must be put in the isr table with IRQ_CONNECT. However, Zephyr's driver is already using IRQ_CONNECT with its own separately defined handler for the gpiote peripheral. So I don't know how my application is even working in the first place using a handler through nrfx gpiote drivers itself with the RTT logger open. I would like to get some clarity on how interrupt handlers directly configured with nrfx gpiote are able to coexist with Zephyr's GPIO driver which connects the gpiote interrupt to its own handler with IRQ_CONNECT. Does the nrfx gpiote driver call IRQ_CONNECT on its handler somewhere that I can't find? I thought that had to be externally done by the application. Or does Zephyr's GPIO driver somehow call the nrfx gpiote handler
Thank you for taking your time to read this. If I can gain some insight into why my GPIO ISRs aren't running/ aren't able to context switch in order to unblock a thread unless the RTT logger output is open would be greatly appreciated!
