Interrupt seems to be starving main loop, but timing doesn't agree.

[coder123]

Hi all,

I have a problem that seems very simple, but I cannot make sense of it.

I have a simple setup on the NRF52840 DK that senses a rising edge on pin 1.00 and then sets pin 1.01 high along with a flag. I then have a while loop in my main that is waiting for this flag to be set high and then sets the pin back low. The interrupt is routinely coming in every 4ms, however my main while loop is never running. I do not understand why. Code below:

GPIO Init and ISR:

Main While() loop:

The variable names are reused from another project, but the reg_readings and biss_readings counter values are output every second to see how many iterations occurred in each loop over the last second. The reg_readings (ISR) counter is coming back 250 consistently so I know it is working. The biss_reading conter comes back as "1" he first time and then "0" every time after tht:

An interrupt firing every 4ms should not be fast enough to starve anything. I also measured how long the ISR is taking by toggling the GPIO pin in it and measuring on an o-scope. It is taking roughly 1-2uS, so definitely not a problem there.

In my 

nrfx_gpiote_init() call when initializing GPIOs, I give the interrupt priority level as 7 which to my knowledge is the lowest priority. Even if it was the highest priority it should not be starving anything.

I must be missing something obvious here. Where is my program if it is not running in the main while loop between interrupts?

Thank you for any help.

[coder123]

Apparently adding a 

k_sleep(K_NSEC(1));

to the bottom of the while loop makes it work. Not exactly sure why but good enough.

[Susheel Nuguru]

It is not clear where (which context) you are printing those logs. It is not clear what other contexts exist in your application.

If k_sleep helped you in your case, then it could be that where ever you introduced the k_sleep will invoke the RTOS scheduler to possible make other contexts run. 

It looks like you do not have good control on which contexts are running when. To be able to calibrate the thread priorities and timing, I strongly recommend you to run your application with Tracing using SystemView

You will get a nice visual view of what thread is blocking which thread like below and this helps you calibrate your thread priorities.