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.