K_Timer and RTC Integration

[Rahul Gavade]

We are using the nRF5340 with Zephyr OS v3.6.99-100befc70c74 and nRF Connect SDK v2.7.0-5cb85570ca43. We have the following questions:

1. Is our understanding correct that the K_Timer utilizes the RTC and operates in the interrupt handler mode of the RTC?

2. What is the tick duration when using the K_Timer with RTC?

   when,
   CONFIG_TICKLESS_CAPABLE=y

   CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=32768

   CONFIG_SYS_CLOCK_TICKS_PER_SEC=32768

   CONFIG_SOC_NRF53_RTC_PRETICK=y

   CONFIG_SOC_NRF53_RTC_PRETICK_IPC_CH_FROM_NET=10

   CONFIG_SOC_NRF53_RTC_PRETICK_IPC_CH_TO_NET=11

3. Is there a mechanism to generate a software timer that counts the delay without running in the interrupt handler?

[Einar Thorsrud]

Hi,

Is our understanding correct that the K_Timer utilizes the RTC and operates in the interrupt handler mode of the RTC?

Yes, Zephyr uses an RTC intance for keeping track of time. The kernel handles the interrupts though, and if you use APIs like k_sleep, or delayed work queue itims etc this the applicaiton processing happens in thread mode.

What is the tick duration when using the K_Timer with RTC?

Here, you have CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=32768 which is default, and is the highest resolution you can have as the RTC runs of the 32.768 kHz clock. This gives a tick duration of 1/32768 Hz = 30.5 us.

Is there a mechanism to generate a software timer that counts the delay without running in the interrupt handler?

Zephyr provide several APIs based on the RTC, and in most cases several are suitable and you need to choose. See Kernel Timing for an overview. There are also conseptcs like delated work queues, you can use dedicated threads that sleep with k_sleep, etc.

[Rahul Gavade]

If we disable the RTC interrupt using irq_disable(RTC1_IRQn);, what will be the effect on a thread that employs k_sleep()? Will it be halted?

[Einar Thorsrud]

Yes, you should not make any changes in the RTC1 configuration as that is reseved by the Zephyr kernel (for the timekeeping that we have discussed here).

[Rahul Gavade]

Thanks for your response Einar, 

Does an event-based thread, such as one using k_event_wait(), experience any specific effects, If we disable the RTC interrupt using irq_disable(RTC1_IRQn)?

[Einar Thorsrud]

Yes, it will experience significant effects, as you are disabling the interrupt that the kernel use for tmiming. You cannot disable interrupts for RTC1.

[Rahul Gavade]

Einar,
Recently we have implemented XIP where our partial code is located in External Flash and internal flash. Same external flash is being used to store the data/logs.
We observed random hard faults when two treads trying to chess external flash
1. Task A tried to erase/write data into the external flash (1 sector = 4kb takes 40 msec).
2. If task B got scheduled when external flash is busy in previous operation and tried to fetch next instruction from External flash (XIP).
3. After Step 2 we observed the hard fault and fault log shows PC = External Flash address where our partial code is present.

Current State:-
We have suppressed this issue by disabling the RTC Interrupt before executing any external flash operation. with this change we don't see any Hard Fault so far.
1. In Task A, disabled the RTC Interrupt
2. Called Erase/Write Operation
3. wait till operation gets completed using Semaphore
4. Re-enabled the RTC interrupt

We have few question on this as follows
Q 1. In step no 3 control should have been transferred from Task A to Scheduler. now scheduler should select next READY task from ready list, is our understanding correct?

Q 2. Can you guess any reason behind this Hard fault?

[Einar Thorsrud]

Hi,

1,. Your understanding is correct. You can read an overveiw of the scheduler workings here. If you cannot handle interrupts for a small period of time, it would be cleaner to disable all itnerrupts with irq_lock()/irrq_unlock().

2. There are several potential problems with XIP and interrupts (see this related thread and this post), but some debugging would be needed to say what exactly happens in your case. Generally, you should avoid interrupds while using XIP, and if possible, avoid XIP alltogether (in case that is possible by rearanging the falsh layout and optimization).