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...

[trafficode]

I can't do it in that way. Those "external effects" - You mean feedback delay... are desirable. It depends on kind of used hardware layer to implement this type of serial interface. In this way there is 1us delay but there is also another usage/hardware where is 80us and this problem not occur.

Like I said. I have implemented "temporary" solution and problem isn't occure right now. I didn't tests this with nrf_power_task_trigger(NRF_POWER, NRF_POWER_TASK_CONSTLAT) yet, maybe problem won't occure.

[trafficode]

When RADIO(bluetooth) is added to project, then erase page time is not const and it is between 90-180ms(20 trys) when no bluetooth enabled this is constant 87ms.

I'm using RC HF CLOCK, in project configuration file I have those two lines:

# RC as Low Frequency clock
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_250PPM=y

But, like I mention before, currently I'm developing two projects parallel. One of them is based on nrf52832 and second one use nrf52833. Clock source type, configuration and hardware close around those cpu are the same. And on nrf52832, erase and write takes max 6ms in case of nrf52833 erase and write takes about 100ms. I use the same zephyr's api and I use storage partition
storage_partition: partition@7a000 {
label = "storage";
reg = <0x0007A000 0x00006000>;
};
I have tested this erase time on dk too, and results are the same as withim our custom board.

[trafficode]

To be honest, I really need answer what is a time that I have to assume for erasing and writing page... Is that <5ms like it is in case of usage nrf52832 or should I also expect time about 100ms for this cpu... Using ble couse longer time of operation on flash... so, there is some lock/mutex used on flash driver layer, can I access to this mutex make my code more safety?

[Susheel Nuguru]

In the case that you have one event that can

1. has the interrupt enabled with respect to that event and
2. the same event is connected to gpiote and the gpiote interrupt also enabled 

then there is no guarantee in the order in which the actual interrupt from the timer or gpiote were pended to the ARM NVIC registers. It is possible that there is implementation specific delays which are most of the time consistent in the order they are fired and rarely they can be different. 

Also, it is not clear what the ARM cortex M4 does when two different NVIC bits are set at once? then the NVIC has to break a tie using the hardware priorities. It might be possible that the GPIOTE (peripheral index 6) be having higher priority in the tie breaking scenarios with Timer (peripheral id 8). 

In anycase, you should not create a system which is that time critical as this and give the same priorities to both modules. There are good enough depth of priorities that you can use on the interrupts to solve this problem.

[trafficode]

Susheel Nuguru said:

In anycase, you should not create a system which is that time critical as this and give the same priorities to both modules. There are good enough depth of priorities that you can use on the interrupts to solve this problem.

I understand. This problem like I said is fixed and hundred of thousand tests passed. Worst thing for is flash issue that I mention few posts above. Susheel Nuguru Please take a look on them and give me some answer. Big thank You for Your help.