Here is the code that I tried, and it seems to be working nicely:
https://github.com/apache/nuttx/pull/9546
On Thu, Jun 15, 2023 at 9:59 PM Fotis Panagiotopoulos
wrote:
> > Well, I agree that substituting a delay of one tick instead of using
> > zero is not a useful solution. Calling the expir
> Well, I agree that substituting a delay of one tick instead of using
> zero is not a useful solution. Calling the expiration logic with no
> delay would be better. The error handling is not good.
>
> However, I still say that the root cause of the problem is the logic
> running on the LP work t
On 6/7/2023 2:38 PM, Fotis Panagiotopoulos wrote:
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.
The watchdogs, by design, ask for a single tick delay.
Here it is:
https://github.com/apache/nutt
> 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.
The watchdogs, by design, ask for a single tick delay.
Here it is:
https://github.com/apache/nuttx/blob/master/sched/wdog/wd_start.c#L406
When the
> 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
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, th
> 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...
I would like to think of it a bit more, too.
But I believe that the error is always there.
If you keep the timer running, yo
On Wed, Jun 7, 2023 at 3:39 PM Fotis Panagiotopoulos
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 w
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.
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 valu
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 re
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_
12 matches
Mail list logo
