repeating timer not working if set to 8399ms #1550

Closed
opened 2023-11-16 23:07:50 -06:00 by ruehlchris · 4 comments
ruehlchris commented 2023-11-16 23:07:50 -06:00 (Migrated from github.com)

Hi,
while I working on a reliable reproduction of #1531, I run into this bug:

I set the Timervalue for the repeating timer to 8399ms and the watchdog to (8399 * 2) the repeating timer isn't firing
at all and the watchdog is rebooting in a loop.

example code:
multicore-repeattimer.zip

namespace {
const int32_t TIMERVALUE = 8399; /* fire timer every xx mseconds */
const int32_t WATCHDOGTM = TIMERVALUE * 2;
}

if (add_repeating_timer_ms(TIMERVALUE, timer_callback, nullptr, &_timer))
watchdog_enable(WATCHDOGTM,false);

timer_callback() is feeding the watchdog.

please note:
the main() is deadlock with mutex in the while(true) on purpose!

Hi, while I working on a reliable reproduction of #1531, I run into this bug: I set the Timervalue for the repeating timer to 8399ms and the watchdog to (8399 \* 2) the repeating timer isn't firing at all and the watchdog is rebooting in a loop. example code: [multicore-repeattimer.zip](https://github.com/raspberrypi/pico-sdk/files/13387525/multicore-repeattimer.zip) namespace { const int32_t TIMERVALUE = 8399; /* fire timer every xx mseconds */ const int32_t WATCHDOGTM = TIMERVALUE \* 2; } if (add_repeating_timer_ms(TIMERVALUE, timer_callback, nullptr, &_timer)) watchdog_enable(WATCHDOGTM,false); timer_callback() is feeding the watchdog. please note: the main() is deadlock with mutex in the while(true) on purpose!
peterharperuk commented 2023-11-20 05:57:03 -06:00 (Migrated from github.com)

Isn't this expected? The max time for the watchdog is ~8.3 seconds?

Isn't this expected? The max time for the watchdog is ~8.3 seconds?
ruehlchris commented 2023-11-20 18:51:39 -06:00 (Migrated from github.com)

I my opinion it is not expected that the Watchdog is triggered because set twice the time of the repeating timer , therefore will be restarted always if the repeating timer is working correct.
But in my finding the repeating timer is not start at all.

I my opinion it is not expected that the Watchdog is triggered because set twice the time of the repeating timer , therefore will be restarted always if the repeating timer is working correct. But in my finding the repeating timer is not start at all.
boretrk commented 2023-12-01 09:59:02 -06:00 (Migrated from github.com)

IMO the problem here is that if you try to set the watchdog to a too high value it silently cuts it down to 8.3s

        load_value = delay_ms * 1000 * 2;

        if (load_value > 0xffffffu)
            load_value = 0xffffffu;

If your code typically feeds the watchdog more often but you have a valid situation where 8.3s isn't enough you might end up in a situation where the watchdog doesn't behave as expected.
I think that there at least should be an assert(load_value <= 0xffffffu); in there.
Or even better: assert(delay_ms <= 8389); to catch possible integer overflows when delay_ms is more than 2147484.
(8389*2000 will be more than 0xffffffu, but only by 785.

IMO the problem here is that if you try to set the watchdog to a too high value it silently cuts it down to 8.3s ``` load_value = delay_ms * 1000 * 2; if (load_value > 0xffffffu) load_value = 0xffffffu; ``` If your code typically feeds the watchdog more often but you have a valid situation where 8.3s isn't enough you might end up in a situation where the watchdog doesn't behave as expected. I think that there at least should be an `assert(load_value <= 0xffffffu);` in there. Or even better: `assert(delay_ms <= 8389);` to catch possible integer overflows when delay_ms is more than 2147484. (8389*2000 will be more than 0xffffffu, but only by 785.
ruehlchris commented 2023-12-01 22:55:33 -06:00 (Migrated from github.com)

Peter,
wow - that is an unexpected limitation.
I agree with add an assert() to give a clear warning, it will help a lot to avoid the issue I run into.

I will close this issue now. Thanks for your help!

Chris

Peter, wow - that is an unexpected limitation. I agree with add an assert() to give a clear warning, it will help a lot to avoid the issue I run into. I will close this issue now. Thanks for your help! Chris
Sign in to join this conversation.
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gh-raspberrypi/pico-sdk#1550
No description provided.