Timer and GPIOTE interrupts priorities

[trafficode]

Hello!

I use NRF Connect SDK 1.8.0, but peripherials are configured using nrfx library.

My task is to implement serial interface where I have PIN_TX and PIN_RX. I transmit data over PIN_TX, when I'm transmitting data on PIN_TX I've got feedback on PIN_RX. On oscilloscop I can see that delay beetwen set PIN_TX and got feedback on PIN_RX is about 1us delay(electronic circuit delay).

PIN_TX is driven in Timer Output Compare mode but PIN_RX work in Timer Input Copture mode. Timer Output Compare interrupt is enabled and GPIOTE interrupt is enabled as well. They are configured with the same interrupt priority, let's say IRQ_PRIO_LOWEST-2.

Haw does situation looks 99.99% cases

1. Output Compare Event occur and PIN_TX has been toggle

2. Timer Output Compare interrupt occured

3. GPIOTE interrupt occured and I can read timer compare value that has been captured

But, sometimes situation looks a little bit different...

1. Output Compare Event occured and PIN_TX has been toggle

2. GPIOTE interrupt occured and I can read timer compare value that has been captured
3. Timer Output Compare interrupt occured

This situation never occur when I configure Timer whit higher priority than GPIOTE but then I have other problems...

The questions are:

* Interrupt can interrupt other interrupt with the same priority? (to this day I have been convinced that it is not)

* Is that mybe known problem and there is some solution to fix it? I have not so big experience with nrf52. I have never had similar situation when I was working with stm32...

[Susheel Nuguru]

* Interrupt can interrupt other interrupt with the same priority? (to this day I have been convinced that it is not)

On ARM Cortex M4 same priority interrupts cannot pre-empt an existing interrupt with same priority. Are you toggling some gpios that are connected to compare event to measure the distance or do you rely on interrupt service routines for few measurements?

This is purely ARM related implementation and I have not heard that there is a bug in priority handling in such contexts. 

* Is that mybe known problem and there is some solution to fix it? I have not so big experience with nrf52. I have never had similar situation when I was working with stm32...

I am quite confident that there is no known problem in context prioritizing within ARM controller. 
I need to understand more on how you concluded that it could be priority issue. If you have ISR involved in any of these measurements, then I can say that the timings of ISR running are not the same as the timings of interrupt happening. 

[hmolesworth]

There is a simple test you can do to isolate the external effects of the TX_PIN and RX_PIN  connection (which includes pin capacitance) by using internal loopback. Change the RX_PIN to instead use TX_PIN (this works, I use it on serial loopback testing) and enable the input thus:

    nrf_gpio_cfg(TX_PIN, NRF_GPIO_PIN_DIR_OUTPUT, NRF_GPIO_PIN_INPUT_CONNECT, NRF_GPIO_PIN_NOPULL, NRF_GPIO_PIN_H0H1, NRF_GPIO_PIN_NOSENSE);

[trafficode]

Now it's clear. But I did about 20k erase/write cycles and still below 5ms on nrf52832 - but of course it could be not a rule.

Thank You for help!

Question from a different barrel...

Is there something wrong with buttons "Reply" "Verify Answer" and "More" at the bottom of posts...? Sometimes they appear but sometimes don't...

[Susheel Nuguru]

trafficode said:

Is there something wrong with buttons "Reply" "Verify Answer" and "More" at the bottom of posts...? Sometimes they appear but sometimes don't...

I have noticed that sometimes too. I'll report that internally. Thanks for the feedback. Since this is a public case, I can mark this thread as verified so that it can help others if that is ok?

[hmolesworth]

I also had trouble for "Reply" or "More" for years, then found that by shrinking the display with Ctrl'-' (Ctrl Minus) all the "Reply" and "More" buttons magically appear. Then after selecting "Reply" I enlarge with Ctrl'+' so I can read easily

[trafficode]

It works for me too :) thx

[trafficode]

Susheel Nuguru said:

I can mark this thread as verified so that it can help others if that is ok?

Yeap :)