From cb5bab34f177a59018c217aaa91c020f64064f39 Mon Sep 17 00:00:00 2001 From: ligd Date: Tue, 10 Sep 2024 12:35:01 +0800 Subject: [PATCH] wdog: always ticks++ when wd_start Now we have CONFIG_USEC_PER_TICK, and for our timer system, all the calculation used 'tick'. And all the timespec should change to 'tick' before use wd_start(), so USEC2TICK() can NOT be avoided. Then there must be an 'less then one tick' loss. One resolution: ticks++ anyway when wd_start(). But this will caused time expired more a tick. Another resolution: Change the testcase, and allow the following logic: t1 = current_time(); sleep(3); t2 = current_time(); allow: t2 - t1 >= 3; (original test must be: t2- t1 > 3) The original test think the time must be elapse-ing, and the (t2 - t1) must bigger then 3, but in our system, we use 'tick' as the minimal wdog unit, then there must a precision loss. Now we choose first resolution. Signed-off-by: ligd --- sched/wdog/wd_start.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/sched/wdog/wd_start.c b/sched/wdog/wd_start.c index 5f9720079fe..1e0a1141d9d 100644 --- a/sched/wdog/wd_start.c +++ b/sched/wdog/wd_start.c @@ -260,6 +260,23 @@ int wd_start_absolute(FAR struct wdog_s *wdog, clock_t ticks, return -EINVAL; } + /* Calculate ticks+1, forcing the delay into a range that we can handle. + * + * NOTE that one is added to the delay. This is correct and must not be + * changed: The contract for the use wdog_start is that the wdog will + * delay FOR AT LEAST as long as requested, but may delay longer due to + * variety of factors. The wdog logic has no knowledge of the the phase + * of the system timer when it is started: The next timer interrupt may + * occur immediately or may be delayed for almost a full cycle. In order + * to meet the contract requirement, the requested time is also always + * incremented by one so that the delay is always at least as long as + * requested. + * + * There is extensive documentation about this time issue elsewhere. + */ + + ticks++; + /* NOTE: There is a race condition here... the caller may receive * the watchdog between the time that wd_start_absolute is called and * the critical section is established.