STM32F4 tickless

[Fotis Panagiotopoulos <f....@gmail.com>]

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?

Re: STM32F4 tickless

[Fotis Panagiotopoulos <f....@gmail.com>]

> 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, you need to check the current counter value,
add your wait period, and set the match register.
Till you do all of these, the counter may have advanced. Its phase will
surely change.
You will always end up waiting less than requested, about the overhead time
of this function.

If you stop the timer, then there is no "time keeping" during the setup of
the timer.
You will always end up waiting more than requested, about the overhead time
of the function.

Thus, the "inaccuracies" are always there.
It is just about choosing between errors towards "more" or "less.

But I am not sure about the accumulation of these errors yet.
It depends on the implementation of the scheduler.



On Wed, Jun 7, 2023 at 10:45 PM Nathan Hartman <ha...@gmail.com>
wrote:

> On Wed, Jun 7, 2023 at 3:39 PM Fotis Panagiotopoulos <f....@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
>

Re: STM32F4 tickless

[Nathan Hartman <ha...@gmail.com>]

On Wed, Jun 7, 2023 at 3:39 PM Fotis Panagiotopoulos <f....@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

Re: STM32F4 tickless

[Fotis Panagiotopoulos <f....@gmail.com>]

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 <f....@gmail.com>
wrote:

> > 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 thread that is actually requesting a delay of
> > zero.  That is a hard error and should never happen.
>
> If this is surely an error, we can add an ASSERT(), so such errors are
> caught.
>
> However, I am also sure that this will break all applications that are
> actually using tickless.
>
> This may be a good thing (tickless is not working correctly, so the user
> is notified),
> or a bad thing (applications that were "ok" are now broken).
>
> ---
>
> There is an alternative approach that will perfectly allow single tick
> delays.
> I just tried a proof-of-concept with success.
>
> Assume a "software prescaller".
> According to this prescaller, the actual value of the hardware timer will
> be scaled-down when fed to the OS.
> And when values are set to the timer, they are scaled-up again.
>
> Let's say that the software prescaler is set to 10.
> This means that the actual hardware timer runs 10 times faster than what
> the OS thinks.
> A single OS tick will have a duration of 10 hardware timer ticks.
>
> With this trick, we can now have control over the phase of the timer.
> Because, even if 1 tick "slips-away", there are still 9 left. The max.
> inaccuracy will be 10%, instead of 100%.
>
> The phase is the key here. When you read the timer, you don't know if you
> are right at the start of the current tick,
> or if it's just about to end. That means that you have an uncertainty of 1
> tick. By breaking it down to smaller bits,
> your uncertainty is only the fraction of the assumed tick. It's like
> having a fractional timer.
>
> (I am sorry, I am not sure if I explained this in an understandable way).
>
> The only problem I see with this approach, is that the maximum wait period
> will also be reduced,
> according to this prescaller.
>
> What do you think?
>
>
>
> On Thu, Jun 8, 2023 at 1:18 AM Gregory Nutt <sp...@gmail.com> wrote:
>
>>
>> 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/nuttx/blob/master/sched/wdog/wd_start.c#L406
>> >
>> > When the wdog->lag is 0, then the delay is set to 1 tick.
>>
>> 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 thread that is actually requesting a delay of
>> zero.  That is a hard error and should never happen.
>>
>>

Re: STM32F4 tickless

[Fotis Panagiotopoulos <f....@gmail.com>]

> 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 thread that is actually requesting a delay of
> zero.  That is a hard error and should never happen.

If this is surely an error, we can add an ASSERT(), so such errors are
caught.

However, I am also sure that this will break all applications that are
actually using tickless.

This may be a good thing (tickless is not working correctly, so the user is
notified),
or a bad thing (applications that were "ok" are now broken).

---

There is an alternative approach that will perfectly allow single tick
delays.
I just tried a proof-of-concept with success.

Assume a "software prescaller".
According to this prescaller, the actual value of the hardware timer will
be scaled-down when fed to the OS.
And when values are set to the timer, they are scaled-up again.

Let's say that the software prescaler is set to 10.
This means that the actual hardware timer runs 10 times faster than what
the OS thinks.
A single OS tick will have a duration of 10 hardware timer ticks.

With this trick, we can now have control over the phase of the timer.
Because, even if 1 tick "slips-away", there are still 9 left. The max.
inaccuracy will be 10%, instead of 100%.

The phase is the key here. When you read the timer, you don't know if you
are right at the start of the current tick,
or if it's just about to end. That means that you have an uncertainty of 1
tick. By breaking it down to smaller bits,
your uncertainty is only the fraction of the assumed tick. It's like having
a fractional timer.

(I am sorry, I am not sure if I explained this in an understandable way).

The only problem I see with this approach, is that the maximum wait period
will also be reduced,
according to this prescaller.

What do you think?



On Thu, Jun 8, 2023 at 1:18 AM Gregory Nutt <sp...@gmail.com> wrote:

>
> 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/nuttx/blob/master/sched/wdog/wd_start.c#L406
> >
> > When the wdog->lag is 0, then the delay is set to 1 tick.
>
> 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 thread that is actually requesting a delay of
> zero.  That is a hard error and should never happen.
>
>

Re: STM32F4 tickless

[Gregory Nutt <sp...@gmail.com>]

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/nuttx/blob/master/sched/wdog/wd_start.c#L406
>
> When the wdog->lag is 0, then the delay is set to 1 tick.

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 thread that is actually requesting a delay of 
zero.  That is a hard error and should never happen.

Re: STM32F4 tickless

[Fotis Panagiotopoulos <f....@gmail.com>]

> 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 wdog->lag is 0, then the delay is set to 1 tick.

On Wed, Jun 7, 2023 at 11:25 PM Fotis Panagiotopoulos <f....@gmail.com>
wrote:

> > 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.
>
> Understood. Also just got verified experimentally.
> The timer must run, by design.
>
> > 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.
>
> I am afraid that this check will not help.
> For this specific problem, you cannot perform any checks.
> Because between the time the check is performed, and the match register is
> loaded,
> the timer may have advanced.
>
> Here is the failure scenario:
> 1. Assume that the timer counter is currently at 100 ticks.
> 2. The scheduler requests a timeout in 1 tick.
> 3. The counter is read (100).
> 4. The match value is calculated (100 + 1 = 101).
> 5. It just so happens that the timer advanced to 101.
> 6. The match register is loaded with the value 101. Now it is too late.
>
> You will have to wait a full timer roll-over for the next match.
>
> No matter where you put the check, the timer will always have the chance
> to "slip" to the next value
> before you had the chance to set the match register (and re-enable the
> interrupt).
>
> > 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.
>
> This is surely happening though!
> I added the following within up_timer_start():
>
> ASSERT(period > 1);
>
> The assertion fails immediately!
>
> I checked at least one occurence, and this is the fault:
>
> sched_unlock() -> nxsched_reassess_timer() -> nxsched_cancel_timer() -> nxsched_timer_process()
> -> wd_timer()
>
> There, there is the watchdog lp_work_timer_expiry that requests a delay of
> 1 tick.
>
> But I am pretty sure there will be other cases of 1 tick wait, though...
>
>
>
>
> On Wed, Jun 7, 2023 at 10:58 PM Gregory Nutt <sp...@gmail.com> wrote:
>
>>
>> > 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.
>>
>>
>>

Re: STM32F4 tickless

[Fotis Panagiotopoulos <f....@gmail.com>]

> 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.

Understood. Also just got verified experimentally.
The timer must run, by design.

> 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.

I am afraid that this check will not help.
For this specific problem, you cannot perform any checks.
Because between the time the check is performed, and the match register is
loaded,
the timer may have advanced.

Here is the failure scenario:
1. Assume that the timer counter is currently at 100 ticks.
2. The scheduler requests a timeout in 1 tick.
3. The counter is read (100).
4. The match value is calculated (100 + 1 = 101).
5. It just so happens that the timer advanced to 101.
6. The match register is loaded with the value 101. Now it is too late.

You will have to wait a full timer roll-over for the next match.

No matter where you put the check, the timer will always have the chance to
"slip" to the next value
before you had the chance to set the match register (and re-enable the
interrupt).

> 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.

This is surely happening though!
I added the following within up_timer_start():

ASSERT(period > 1);

The assertion fails immediately!

I checked at least one occurence, and this is the fault:

sched_unlock() -> nxsched_reassess_timer() -> nxsched_cancel_timer()
-> nxsched_timer_process()
-> wd_timer()

There, there is the watchdog lp_work_timer_expiry that requests a delay of
1 tick.

But I am pretty sure there will be other cases of 1 tick wait, though...




On Wed, Jun 7, 2023 at 10:58 PM Gregory Nutt <sp...@gmail.com> wrote:

>
> > 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.
>
>
>

Re: STM32F4 tickless

[Gregory Nutt <sp...@gmail.com>]

> 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.

Re: STM32F4 tickless

[Fotis Panagiotopoulos <f....@gmail.com>]

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 <sp...@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.panag@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?
> >>
> >>
> >>
>
>

Re: STM32F4 tickless

[Gregory Nutt <sp...@gmail.com>]

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....@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?
>>
>>
>>

Re: STM32F4 tickless

[Fotis Panagiotopoulos <f....@gmail.com>]

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....@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?
>
>
>