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. 

[trafficode]

Susheel Nuguru said:

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?

I'm doing this to measure the distance between edges and in interrupt service runtime I'm verifying if this distance is proper...

Susheel Nuguru said:

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.

I think that this issue is not connected with strictly ARM related implementation couse to triger on compare pin toggle we need to engage gpiote task and ppi peripherials... And this latency can be generated here in my opinion...

I can resolve this issue by using some software trick and by setting timer iqr priority to higher than gpio.

There is one another thing that can has same influence here... I noticed that when I excluded ble stack from project some another latency is provided to measuring distance between edges... Solution that I found is to set NRF_POWER->TASKS_CONSTLAT = 1. Then measuring is much more accurate. What is the way to configure this in right way, is there some zephyr api to this or some nrfx library api to configure this... What are all consequences of setting this to 1...?

 

Next issue is connected with erasing/writing flash memory. I'm developing projects based on nrf52832 and nrf52833, erasing page on first of them takes 2ms but on second of them above 80ms! I found information that this operation can take from 2 - 90 ms on nrf52 mcu's. It means that it depends on cpu production series, every cpu can have this time in range(2, 90), or maybe there is some way configure this time?

[Susheel Nuguru]

trafficode said:

There is one another thing that can has same influence here... I noticed that when I excluded ble stack from project some another latency is provided to measuring distance between edges... Solution that I found is to set NRF_POWER->TASKS_CONSTLAT = 1. Then measuring is much more accurate. What is the way to configure this in right way, is there some zephyr api to this or some nrfx library api to configure this... What are all consequences of setting this to 1...?

There is the nRFX library where you can use nrf_power_task_trigger(NRF_POWER, NRF_POWER_TASK_CONSTLAT). There is no other API tapping into this functionality of constlat register.

trafficode said:

Next issue is connected with erasing/writing flash memory. I'm developing projects based on nrf52832 and nrf52833, erasing page on first of them takes 2ms but on second of them above 80ms! I found information that this operation can take from 2 - 90 ms on nrf52 mcu's. It means that it depends on cpu production series, every cpu can have this time in range(2, 90), or maybe there is some way configure this time?

Is there any RADIO activity while requesting the flash erase? it should not be that much difference in time Which HFLCK are you using? is it XTAL or internal RC HFCLK?

[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?