Ah! Yes this is exactly the cause. Within nxsched_resume_timer(), nxsched_timer_process() sometimes returns only 1 tick!
Later on, up_timer_start() will try to schedule the timer expiration 1 tick in the future. Since we don't know the phase of timer, the scheduled tick may be up to 1 tick less. And since we try to schedule only 1 tick, then in reality the time may be even close to 0! And since all the above need at least some time for the CPU to execute these functions, we can easily end up scheduling something in the past! At least in STM32 there is no protection about scheduling things to the past. As far as I can tell, it would be impossible with the current implementation. --- What I don't really understand is "why" it is implemented like this? During all these calculations, and setting of the match register, the timer is left running. Thus it can run beyond our intended target while we set it. Sanity checks are impossible due to TOCTOU errors. Should the timer be stopped? Then possibly reset to a known value (0?), with a known phase. Then the match register be loaded (that now will be more accurate, since the phase of the clock is known), And then restart the timer. On Wed, Jun 7, 2023 at 10:12 PM Gregory Nutt <spudan...@gmail.com> wrote: > The timer peripheral is a counter with a compare/match interrupt, > right? So the match interrupt is not occurring until the much later > than it should? This sounds like a case where the compare register is > being set in the past, that is, the counter has already incremented past > the compare value and has to wrap around before the match can occur. > Could this be happening? Is there any protection against this. > > This might happen if the delays are very small or if the timer > processing is deferred for a long time, perhaps by another interrupt? > > On 6/7/2023 1:00 PM, Fotis Panagiotopoulos wrote: > > As a first test, I added another (NuttX) watchdog timer, to toggle a > board > > LED. > > > > I can confirm that at some point the NuttX watchdogs stop working. > > I am not sure what is the trigger to this situation, the issue appears > > randomly. > > > > Sometimes the watchdogs get stuck for a couple of seconds and then resume > > operation. > > It just happens that the "stuck" period is less than the timeout period > of > > the HW watchdog timer, and the system does not reboot. > > > > > > On Wed, Jun 7, 2023 at 12:23 PM Fotis Panagiotopoulos < > f.j.pa...@gmail.com> > > wrote: > > > >> Hello > >> > >> I have just started experimenting with tickless on an STM32F427. > >> > >> I had some (configuration) issues initially, but now everything seems to > >> be working correctly. > >> > >> However, after some seconds of operation, the Hardware/STM32 Watchdog > >> timer triggers a system reset. > >> > >> I have configured: > >> - CONFIG_WATCHDOG > >> - CONFIG_WATCHDOG_AUTOMONITOR > >> - CONFIG_WATCHDOG_AUTOMONITOR_BY_WDOG > >> - WATCHDOG_AUTOMONITOR_TIMEOUT = 5 > >> - CONFIG_WATCHDOG_AUTOMONITOR_PING_INTERVAL = 1 > >> > >> So, the HW watchdog is fed by a NuttX watchdog. > >> > >> I don't think that there is a timing issue here (inaccuracy), as the HW > >> watchdog is supposed to be fed every second, > >> while its timeout is set to 5 seconds. It has plenty of time to absorb > any > >> inaccuracies. > >> Also, it's worth mentioning that this configuration works perfectly on > >> traditional systems (non-tickless). > >> > >> I guess that the NuttX watchdogs stop working after some time? > >> > >> Are there any ideas on the possible cause, before I start debugging it > the > >> hard way? > >> Is anyone using tickless on STM32F4's? > >> > >> > >> > >
