How to handle timeout set by sys_clock_set_timeout() being missed?

[HenrikKaa]

I'm trying to use MCUX OSTimer for systick clock but I'm running into a problem where the timeout is so few ticks that by the time the match value is set, the timer has already counted past the match value. I have been able to confirm this is exactly what happens reliably. Logically in this situation I should call sys_clock_announce() but if I do that, the code gets into infinite loop setting timeout and announcing.

Is there some proper way to handle this case or am I running into an unthought issue?

[DerekSnell]

Hi @HenrikKaa ,

It sounds like the tick rate is too fast given the hardware configuration. Can you provide more details about your use-case? What device are you using? What frequencies are clocking the OStimer and the CPU? What tick rate are you trying to achieve?

Thanks

[HenrikKaa]

Some info:

NXP LPC55S69
Core clock 96 MHz, only core0 used
System clock driver MCUX OS Timer
CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=32768
CONFIG_SYS_CLOCK_TICKS_PER_SEC=8192

I'm running quite few threads and multiple i2c and uart devices, if that's relevant. I have also set all other interrupt priorities lower than OSTimer IRQ.

[DerekSnell]

Hi @HenrikKaa ,
Since the OS Timer is clocked at 32 kHz, accessing the counter registers are also synchronized to that slow clock. It appears you are ticking the kernel every 4 counter ticks of the slow clock. And as I recall, the OS Timer counts in gray code, so the driver converts gray code to decimal if you want to interact with the timer. Given the slow clock, if SW is trying to read/write these registers with only a couple cycles, I am not surprised you are seeing issues with this. I do not think this is a viable solution.

But I am curious, why are you trying to clock the kernel like this? By default, the LPC5569 uses the SysTick timer at 96 MHz.

Best regards

[HenrikKaa]

The choice to use OS Timer instead of systick was made to simplify power down modes. Unlike systick, OS Timer can operate in all power modes and thus no additional effort is required for keeping correct timing.

About synchronisation, UM11126 mentions there is no latency

Reads of gray-encoded timers are accomplished with no synchronization latency

and

Writes to the match registers are stored in domain bus clock based shadow registers. They are automatically transferred to the actual match registers following a write to the Match_H register. For this reason, the Match_L register must always be written first, followed by the write to the Match_H register.
Reads of the match registers will reflect the value in the bus clock based shadow registers so that a read immediately following a write will always reflect the value just written

Anyway, the original question remains. Regardless of the timer backend used, there should never be a situation where the system gets stuck to idle because timer interrupt was missed.

[DerekSnell]

Hi @HenrikKaa ,
Thank you for these details. I do not yet have a solution for you. It seems this will take deeper investigation to find the root cause, and learn how to enable your use-case.

Best regards