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

[Abcde]

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

[Den64]

У меня в домашней автоматике, периодически, зависает одна задача. Примерно раз в день. Просто передёргиваю питание, могу себе такое позволить. Лень ошибку устранить.
Ну вот как защитит WDT если, я просто запущу ещё один процесс который будет сбрасывать таймер допустим раз в секунду? Ну и будет отдельный процесс сбрасывать, а другой висеть или завершился (бес его знает что там).
100% защиты от софтовой ошибки WDT не даст, да и от аппаратной. Это понятно. Но вот смысл сбрасывать в отдельной низкоприоритетной задаче вижу только в защите от сильной загрузки процессора, и то только в момент сброса. Процессор может быть загружен пол секунды, а в момент работы процесса сброса процессор свободен. Непонятно.

Если планировщик вытесняющий, то это - абсолютно плохая плохая идея!!! , поскольку тогда WDT будет сбрасывает всегда

Планировщик это вообще то не одна строчка кода. И варианты не только перед и после этой строчки.

[Forger]

У меня в домашней автоматике, периодически, зависает одна задача. Примерно раз в день. Просто передёргиваю питание, могу себе такое позволить. Лень ошибку устранить.
Ну вот как защитит WDT если, я просто запущу ещё один процесс который будет сбрасывать таймер допустим раз в секунду?

Тут WDT вообще не поможет. Тут - проблема другого характера:

"лень ошибку устранить"

100% защиты от софтовой ошибки WDT не даст, да и от аппаратной. Это понятно.

WDT существует не для борьбы с ошибками, а совсем для другого - как минимум для защиты от некоторых непредвиденных ситуаций.
WDT создан лишь как дополнение к существующим методам защиты, но не их замена.
Грамотное применение WDT позволить реализовать все его возможности, а не создавать иллюзию от его якобы пользы.

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

В момент сброса процессор сброшен и ничего у него не работает. Вы о чем?

Процессор может быть загружен пол секунды

Если это время измеряется в секундах, то период WDT также должен быть настроен на аналогичный интервал.
А вообще real-time приложение НИКОГДА не должно быть загружено на 100% более, чем допустимое (детерминированное) время реакции на любое событие системы!
В данном случае - полсекунды - это огромное время, за которое в реальном устройстве может успеть произойти очень много неприятностей.

Непонятно.

Читаем матчасть!

Планировщик это вообще то не одна строчка кода. И варианты не только перед и после этой строчки.

Да хоть 500 тыщ строк кода, сути это не меняет.
Угробить функционал WDT очень просто - достаточно лишь сбрасывать его где надо и не надо