On Wed, Jun 7, 2023 at 3:39 PM Fotis Panagiotopoulos <f.j.pa...@gmail.com> wrote:
> 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. If you stop the timer, then wouldn't we gradually accumulate error? Like a gradual clock drift... Not sure yet what to suggest. I need to think about it some more... Nathan
