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]

trafficode said:

# 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

You mentioned that you enabled Bluetooth functionality by enabling the softdevice (BLE protocol stack). If you are using RC as your LFCLK for the softdevice (check NRF_SDH_CLOCK_LF_SRC in your sdk_config.h file) then the softdevice also starts the calibration of this clock based on the calibration configuration that is set in the same file (sdk_config.h). This calibration is triggered at regular intervals as mentioned in NRF_SDH_CLOCK_LF_RC_CTIV or if the temperature of the chip changes. This is very time consuming process (sometimes can take 80ms based on how many rounds of calibration is needed to bring the LF RC clock back to same accuracy). Also flash erase does not happen during an on going radio activity. If your flash operation is requested 

1. During the calibration process or
2. During on going BLE activity (while radio being active) then

the flash operation is queued until the above operation is first completed. 

If you see different times of flash completions then it most likely is due to you using internal RC for your LFCLK for the softdevice. If you have XTAL LFCLK, change the configuration in NRF_SDH_CLOCK_LF_SRC and CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC so that you use XTAL instead of RC. The calibration time can differ for the chips of the same product type and version.

[trafficode]

Let's not focus on the case with ble enabled. To this day I was sure that there is no sdk_config.h in NRF Connect SDK, where should I looking for this file? That's the option and I'm still not sure that I'll enable ble in production version, right now it's only to make debug easier.

One more time... I'm developing two projects right now. One of them is based on nrf52832, there I have about 50 pieces. Within all of them, flash erase time not exceed 5ms. Second project is based on nrf52833 and flash erase time is about 80ms.

Documentation say, that erase time on nrf52 can take ~2-90ms(if I remember well). 5ms and 80ms are in this range. It's a bit wierd that on 50 pieces with nrf52832 it is 5ms but it is so much more using nrf52833.

Should I expect that this erase time for both cpu's(nrf52832 and nrf52833) can be in this range...??? Let's say, it is possible that on some pieces with nrf52832 erase can take 80ms and on some pieces on nrf52833 can take 5ms???

[Susheel Nuguru]

trafficode said:

To this day I was sure that there is no sdk_config.h in NRF Connect SDK, where should I looking for this file?

Sorry no, there is no sdk_config.h file in nRF Connect SDK and I got confused answering threads on both SDKs. These settings are the default from the template project you took for your project or this settings must have been set in the proj.conf. 

trafficode said:

Should I expect that this erase time for both cpu's(nrf52832 and nrf52833) can be in this range...??? Let's say, it is possible that on some pieces with nrf52832 erase can take 80ms and on some pieces on nrf52833 can take 5ms???

I had found some older discussions on this and this info was new to me aswell. So to answer your question, 

the flash in nRF52832 is a special one. it has a variable erase time per page, between 2 and 80-something ms. This is based on the flash wear of each page. This means that in the beginning of the specific nRF52832 lifetime, the erasetime is quicker, and after doing X amount of erase cycles, it will become slower. Other nRF52-series devices have a fixed erase time. 

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