Как правильно использовать сторожевой таймер с РТОС?, wathdog timer, RTOS Опции

[Abcde]

Сейчас период таймаута выбран 0,5 сек, обнуление счетчика сторожевого таймера происходит в одной задаче РТОС, которая начинает выполняться только через 1 секунду после подачи питания (такая особенность). Получается сторожевой таймер срабатывает раньше…
Где должен обнуляться счетчик сторожевого таймера? Сейчас он обнуляется в одной из задач РТОС, почти безусловно, т.е. контролируется только правильность работы этой задачи. Как контролировать остальные, особенно если они взаимосвязанные (ждут результатов работы других задач)?
Или задачи во время своего выполнения сами должны анализировать себя и сигнализировать выше, но если РТОС вытесняющая, то задача может прерваться и анализ оказаться неполным или не быть готовым к моменту принятия решения о сбросе по сторожевому таймеру. Как тут быть?
Обязательно ли проводить самодиагностику сторожевого таймера при подаче питания (когда ждем сброса по срабатыванию сторожевого таймера, а после него фиксируем успешность его работы и загружаемся как обычно). Но это ограничивает период таймаута сторожевого таймера, чтобы долго не загружать устройство.
Спасибо!

[ViKo]

О, про WWDT я и забыл, а когда видел, путал с AWD, где задается окно ADC. Выходит, WWDT подходит именно для программы, работающей периодично. Планировщик задачи - самое то.
Сбрасывать сторожевой таймер в низкоприоритетном процессе - это хорошо, но как быть, когда высшие задачи забрали все время? Можно создать задачу с высоким приоритетом, которая только и сбрасывает таймер. Все остальные зависания задач разруливать средствами ОС.

[Forger]

Выходит, WWDT подходит именно для программы, работающей периодично.

Нет, он создан для любых программ.
Причем WWDT значительно упрощает прохождение тестов на безопасность приложения (медицина, космос и т. п.).

Планировщик задачи - самое то.

Нет, т.к. планировщик будет вызван в любом случае, ведь системный таймер работает всегда (речь про вытесняющую многозадачность).

Сбрасывать сторожевой таймер в низкоприоритетном процессе - это хорошо, но как быть, когда высшие задачи забрали все время?

Вот тут я расписал самый на мой взгляд простейши способ применения WWDT:
https://electronix.ru/forum/index.php?showt...p;#entry1549577
Сложные (правильные) способы подразумевают связь остальных задач с этой задачей WWDT.
Тогда она превращается в некую deamon-задачу, которая умеет мониторить сбои в других задачах. Так сделано в embOS.
Сложные ситуации могут состоять не из одной сторожевой задачи, а из как минимум двух - в одной низкоприоритетной работает WWDT, в другой - высокоприоритетной - контроль зависания задач.

Можно создать задачу с высоким приоритетом, которая только и сбрасывает таймер. Все остальные зависания задач разруливать средствами ОС.

Лучше наоборот - с самым высоким. Или в прерывании.

В таких случаях WDT становится бесполезным - ему ничто не мешает быть сброшенным.
"The watchdog should never be kicked from an interrupt routine” (MISRA Report 3, p. 38)

Вот вам немного литературы для "подумать": https://barrgroup.com/Embedded-Systems/How-...hdog-Timer-Tips

У большинства коммерческих RTOS существуют даже целые API для правильного применения WDT в критичных приложениях.
https://blog.segger.com/using-a-watchdog-in...os-environment/