Timer and GPIOTE interrupts priorities

RE: Timer and GPIOTE interrupts priorities

trafficode — Tue, 18 Oct 2022 18:51:19 GMT

[quote userid="6207" url="~/f/nordic-q-a/92043/timer-and-gpiote-interrupts-priorities/391095"] I can mark this thread as verified so that it can help others if that is ok?[/quote]

Yeap :)

RE: Timer and GPIOTE interrupts priorities

trafficode — Tue, 18 Oct 2022 18:50:49 GMT

It works for me too :) thx

RE: Timer and GPIOTE interrupts priorities

hmolesworth — Tue, 18 Oct 2022 15:22:39 GMT

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

RE: Timer and GPIOTE interrupts priorities

Susheel Nuguru — Tue, 18 Oct 2022 07:41:54 GMT

[quote user="trafficode"]Is there something wrong with buttons "Reply" "Verify Answer" and "More" at the bottom of posts...? Sometimes they appear but sometimes don't...[/quote]

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?

RE: Timer and GPIOTE interrupts priorities

trafficode — Tue, 18 Oct 2022 06:56:17 GMT

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

RE: Timer and GPIOTE interrupts priorities

Susheel Nuguru — Mon, 17 Oct 2022 06:43:16 GMT

[quote user="trafficode"] To this day I was sure that there is no sdk_config.h in NRF Connect SDK, where should I looking for this file?[/quote]

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.

[quote user="trafficode"]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???[/quote]

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.

RE: Timer and GPIOTE interrupts priorities

trafficode — Tue, 11 Oct 2022 07:13:33 GMT

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

RE: Timer and GPIOTE interrupts priorities

Susheel Nuguru — Tue, 11 Oct 2022 05:33:33 GMT

[quote user="trafficode"]

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

[/quote]

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

During the calibration process or
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.

RE: Timer and GPIOTE interrupts priorities

trafficode — Mon, 10 Oct 2022 13:26:37 GMT

[quote userid="6207" url="~/f/nordic-q-a/92043/timer-and-gpiote-interrupts-priorities/390025"]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.[/quote]

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.

RE: Timer and GPIOTE interrupts priorities

Susheel Nuguru — Mon, 10 Oct 2022 13:07:30 GMT

In the case that you have one event that can

has the interrupt enabled with respect to that event and
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.

RE: Timer and GPIOTE interrupts priorities

trafficode — Mon, 10 Oct 2022 09:18:50 GMT

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?

RE: Timer and GPIOTE interrupts priorities

trafficode — Tue, 04 Oct 2022 11:41:44 GMT

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.

RE: Timer and GPIOTE interrupts priorities

trafficode — Tue, 04 Oct 2022 11:13:45 GMT

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.

RE: Timer and GPIOTE interrupts priorities

Susheel Nuguru — Mon, 03 Oct 2022 17:38:51 GMT

I should have asked you this in the very beginning, but before I test this I need to know if this is on custom hardware or on our nRF52833 DK? If you are using custom hardware and If you have not already tested this on the DK, I would recommend you to test it first on DK to see if it is the same behavior.

RE: Timer and GPIOTE interrupts priorities

hmolesworth — Mon, 03 Oct 2022 15:38:57 GMT

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);

RE: Timer and GPIOTE interrupts priorities

Susheel Nuguru — Mon, 03 Oct 2022 12:04:39 GMT

[quote user="trafficode"]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...?[/quote]

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.

[quote user="trafficode"]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?[/quote]

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?

RE: Timer and GPIOTE interrupts priorities

trafficode — Thu, 29 Sep 2022 07:28:12 GMT

[quote userid="6207" url="~/f/nordic-q-a/92043/timer-and-gpiote-interrupts-priorities/386624"]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?[/quote]

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

[quote userid="6207" url="~/f/nordic-q-a/92043/timer-and-gpiote-interrupts-priorities/386624"]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.[/quote]

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?

RE: Timer and GPIOTE interrupts priorities

Susheel Nuguru — Fri, 16 Sep 2022 11:48:47 GMT

[quote user=""]* Interrupt can interrupt other interrupt with the same priority? (to this day I have been convinced that it is not)[/quote]

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.

[quote user=""]* 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...[/quote]

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.