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

[Abcde]

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

[Baser]

Обычно период сторожевика выбирают от внешних условий работы. Чем ответственней применение и чем печальней могут быть последствия подвисания МК, тем меньше период. И уже исходя из периода так планируют программу, чтобы при нормальной работе софта гарантированно уложиться до автосброса.

Я обычно обслуживаю сторожевик в средне-низкоприоритетной задаче, которая вызывается регулярно со временем в несколько раз чаще периода сторожевика. Остальные важные регулярные задачи выставляют флаги, а та задача исходя из них сбрасывает сторожевик.
Нерегулярные задачи, которые могут не возникнуть за период сторожевика, не контроллирую.

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

Про такое даже никогда не слышал, хотя возможно это и имеет смысл в параноидально-ответственных приложениях

[jcxz]

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

Я контролирую все задачи. Нерегулярные в том числе (те, которые ждут какого-то события, потом его обрабатывают?) - посылаю им пинг (пустое событие), на который они должны ответить.
Все задачи построены в виде циклов ожидания/обработки события, схематически:

Код

while (1) {
  WaitForEvent(...);  //ожидание eventa ОС
  ILive(TASK_ID_...);
  if (!needForService) continue;
  ...
}

В ILive() контролируемая задача посылает контролирующей сообщение, что она жива (ставит флажок например).
Регулярные построены точно так же - без разницы.
Контролирующая, после установки состояния "проверка состояния задачи TASK_ID...", перестаёт генерить WDI до того момента, пока контролируемая задача не вызовет ILive().
Таким образом проверяется, что задача выполняет главный цикл своего функционирования (не заблокировалась например на каком-то ожидании или dead-lock-е) в хвосте главного своего цикла.

[Arlleex]

Контролирующая, после установки состояния "проверка состояния задачи TASK_ID...", перестаёт генерить WDI до того момента, пока контролируемая задача не вызовет ILive().
Таким образом проверяется, что задача выполняет главный цикл своего функционирования (не заблокировалась например на каком-то ожидании или dead-lock-е) в хвосте главного своего цикла.

На самом деле интересная идея, но не совсем понятно, как именно отслеживается зависание. Ну не ответила задача - вполне может быть, что у неё время выполнения большое. Не совсем понял Вашего механизма, если честно. Да и период пингуюшей задачи, не понятно, должен ли как-то зависеть от периодов задач, которые подвергаются контролю?

[jcxz]

Ну не ответила задача - вполне может быть, что у неё время выполнения большое.

Не должно быть такого. У любой задачи должно быть строго известное время максимальной задержки ответа. Не ответила - перезагрузка.

Да и период пингуюшей задачи, не понятно, должен ли как-то зависеть от периодов задач, которые подвергаются контролю?

Никак. Он должен быть меньше времени таймаута WDT.