Later on, up_timer_start() will try to schedule the timer expiration 1 tick
in the future.
This is, ultimately, the problem. You can't wait for one tick. There is
something wrong with the delay that is asking for the single tick delay.
If the single tick delay is valid for some reason, then there is no
clean work-around: Increase the delay? Ignore the delay?
I don't think this should happen. I think it is a bug of some kind.
For example, if interrupts are disabled for a long time so that interval
timer processing is delayed. Then the delay value can be small or even
negative, I suppose.
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.
It is possible if you make an assumption like "the maximum delay cannot
be larger than half the range of clock". Then if the implied delay is
larger than half the range of the clock, then you can assume that we
tried to schedule something in the past.
A better check would be to calculate the number of ticks until the
match. This should be the same as the delay +/- a few ticks.
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.
Yes, it is a free-running timer and represents the current time. It is
read whenever anything asks for the current time. It is read frequently
during the interval timer interrupt processing to avoid/minimize
situations like you describe.
Should the timer be stopped?
You can't stop it or it no longer represents the current time.
