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

[Abcde]

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

[ViKo]

1. Впервые слышу про сторожевой таймер в МК, который должен быть сброшен не ранее определенного времени.

2. Специально озадачиваться тем, чтобы все задачи работали впустую только для того, чтобы сбрасывать сторожевой таймер, считаю разновидностью паранойи.

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

4. Сбрасывать сторожевой таймер в прерываниях - в корне неверно, поскольку основная программа может уже безнадежно висеть.

5. Если РТОС зависает из-за неправильно заданной передачи управления между задачами, то таймер нужно встроить программисту в нутро.

[Forger]

1. Впервые слышу про сторожевой таймер в МК, который должен быть сброшен не ранее определенного времени.

(С) "Век живи - век учись!"
Например, в STM-ках есть WWDT - Window WDT...
Вообще, в идеале, WDT должен тактироваться от собственного независимого генератора (в нормальных МК есть даже несколько разных WDT, в т.ч. "аналоговых").
При схеме, которую я описал выше, любой сбой системной частоты, от которой тактируется системный таймер ОС, вызовет несвоевременный сброс WDT, что вызовет всегда сброс проца.
Т. е. оконный WDT позволяет еще и бороться со сбоями тактовой частоты (банально коснулись пальцем выводов кварца), т. е. WDT "контролирует" связь приложения с реальным временем.

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

Если планировщик вытесняющий, то это - абсолютно плохая плохая идея!!! , поскольку тогда WDT будет сбрасывает всегда безусловно "благодаря" прерываниям от системного таймера и сервисами ОС, вызываемыми из других прерываний (семафоры/сообщения из прерываний).
Приложение давно висит, но данные снаружи сыпятся, вызывают прерывания, те уже семафорят (будят) задачи и тем самым безусловно вызывают планировщик, а тут сбрасывается WDT ... короче, в такой схеме WDT вообще бесполезен!

Фактически это то же самое, что и сбрасывать WDT в прерываниях:

4. Сбрасывать сторожевой таймер в прерываниях ....

5. Если РТОС зависает из-за неправильно заданной передачи управления между задачами, то таймер нужно встроить программисту в нутро.

WDT в принципе не должен ничего знать о принципах и стратегиях построения приложения. WDT - полностью независимый "орган", и работать он должен не предвзято.
Проект может меняться как угодно, а WDT - как работал так и должен работает. Ему все это должно быть "до лампочки". В противном случае проку от такого WDT не будет.
Кстати, в серьезных проектах работа WDT всегда проверяется - пишутся соотв. тесты, в т. ч. аппаратные: сбои тактирования, питания, повреждения содержимого ОЗУ (например, радиацией для соотв. применений).