timers: large drift if hardware timer has a low resolution

[jeppenodgaard]

Describe the bug
When a k_timer has a low period and the hardware clock has a low resolution timers drift.

• What target platform are you using: mimxrt1050_evk
• What have you tried to diagnose or workaround this issue: change gpt_hw_timer to systick in mimxrt1050_evk.dts to increase the clock resolution.
• Is this a regression: Maybe. The gpt_hw_timer was introduced to here: Enable using GPT timer as OS Timer on RT1xxx boards #39449. Before that

To Reproduce
Steps to reproduce the behavior:

1. Replace the code in samples/hello_world/main.c:

#include <zephyr/kernel.h>

#define PRINT_MS	10000
#define SLEEP_MS	1

void my_work_handler(struct k_work *work)
{
	static int i = 0;

	if (++i == (PRINT_MS / SLEEP_MS)) {
		printk("hello from timer\n");
		i = 0;
	}
}

K_WORK_DEFINE(my_work, my_work_handler);

void my_timer_handler(struct k_timer *dummy)
{
    k_work_submit(&my_work);
}

K_TIMER_DEFINE(my_timer, my_timer_handler, NULL);

void main(void)
{
	k_timer_start(&my_timer, K_MSEC(SLEEP_MS), K_MSEC(SLEEP_MS));

	while(1) {
		static int i;

		if (++i == (PRINT_MS / SLEEP_MS)) {
			printk("hello from main\n");
			i = 0;
		}
		k_msleep(SLEEP_MS);
	}
}

2. west build -p -b mimxrt1050_evk zephyr/samples/hello_world/ && west flash

Expected behavior
No or maybe a couple of ms drift between prints.

Impact
What impact does this issue have on your progress (e.g., annoyance, showstopper)

Logs and console output
Using gpt_hw_timer:

[14:43:00.591] *** Booting Zephyr OS build zephyr-v3.2.0-7-g4cce8822946e  ***
[14:43:00.596] hello from main
[14:43:10.848] hello from main
[14:43:13.109] hello from timer
[14:43:21.100] hello from main
[14:43:25.622] hello from timer
[14:43:31.352] hello from main
[14:43:38.134] hello from timer
[14:43:41.603] hello from main
[14:43:50.647] hello from timer
[14:43:51.855] hello from main
[14:44:02.106] hello from main
[14:44:03.159] hello from timer

Using systick:

[14:39:47.136] *** Booting Zephyr OS build zephyr-v3.2.0-7-g4cce8822946e  ***
[14:39:47.141] hello from main
[14:39:57.142] hello from timer
[14:39:57.143] hello from main
[14:40:07.143] hello from timer
[14:40:07.146] hello from main
[14:40:17.145] hello from timer
[14:40:17.149] hello from main
[14:40:27.145] hello from timer
[14:40:27.150] hello from main
[14:40:37.146] hello from timer
[14:40:37.153] hello from main
[14:40:47.147] hello from timer

[dleach02]

@jeppenodgaard, on your target application, you can return to using systick as the timer source. This behavior, or side affect, of changing timers is something to consider when making power tradeoffs. In the PR you referenced, the following comment is in the board DTS to give guidance to switch back if needed:

 /* Enable GPT for use as a hardware timer. This disables Cortex Systick.
  * to use systick, change this node from "gpt_hw_timer" to "systick"
  */
 &gpt_hw_timer {
	status = "okay";
 };

We will look at changing the default back to systick and have GPT used when enabling power management. In the meantime, I'm changing this report to a discussion thread.

[jeppenodgaard]

@dleach02 thank you for clarifying!
The guidance was very useful. However I did not know why I would want to change back.

I think the issue is that I had spend time figuring out why the drift was so high and find the PR to understand why the gpt_hw_timer was chosen.

I think the solution you suggest is great.
An enhancement would be a notification if short timer periods/sleeps are attempted to be used with the GPT. Maybe a LOG_WRN.