Как правильно использовать сторожевой таймер с РТОС?, 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/

[jcxz]

В таких случаях WDT становится бесполезным - ему ничто не мешает быть сброшенным.

В смысле - ничего? Вы безусловно что-ли генерите WDI? Естественно так делать не надо.
Как я писал выше - у меня задача WDT (или это может быть и ISR) контролирует все прочие задачи, формируя WDI только когда очередная контролируемая задача ответила. Т.е. - когда очередная задача сказала что она жива.
Ещё раз (для непонятливых): очередная контролируемая задача ответила на запрос задачи WDT (ISR-а WDT) - задача WDT формирует WDI и переходит к следующей контролируемой задаче (посылает ей запрос). Пока контролируемая задача не ответила - никаких WDI не формируется и через некоторое время будет сброс по WDT. И так - по кольцу все контролируемые задачи.
Под "контролируемыми задачами" я понимаю не только собственно некие задачи ОС, а вообще некие циклические процессы, которые периодически проходят через начальное состояние. Это может быть служба вообще не имеющая задач ОС, а состоящая из машины состояний переключающейся по множеству разных прерываний/событий.
Задача WDT должна быть предельно простой, чтобы минимизировать возможность зависания её самой из-за программного бага в ней.
Задача WDT при переходе к контролю очередного процесса, перед посылкой запроса к нему, записывает в некую переменную информацию о стадии контроля. Эта информация должна сохраниться в ОЗУ при reset-е МК и будет записана в энергонезависимый журнал событий при старте ПО (если при старте ПО будет выявлено, что причина данного старта ПО - предыдущее срабатывание WDT). Таким образом позже можно будет проанализировать какие случаи зависаний возникают и в каких задачах. Именно поэтому задача WDT (или ISR WDT) должны быть самыми высокоприоритетными, чтобы какой-то зависший процесс не привёл к её блокировке и формированию ложной информации о причине сброса по WDT.

Что именно "не мешает быть сброшенным" WDT в этом алгоритме?

"The watchdog should never be kicked from an interrupt routine” (MISRA Report 3, p. 38)

"На каждую хитрую гайку - найдется свой болт с резьбой"...
Вот Вам выдержка из user manual на XMC4500 касательно режима Pre-warning Mode WDT:
While in pre-warning mode the effect of the overflow event is different with and without
pre-warning enabled. The first crossing of the upper bound triggers the outgoing alarm
signal wdt_alarm when pre-warning is enabled. Only the next overflow results a reset
request. The alarm status is shown via register WDTSTS and can be cleared via register
WDTCLR. A clear of the alarm status will bring the WDT back to normal state. The alarm
signal is routed as request to the SCU, where it can be promoted to NMI.
Т.е. - Infineon специально заложил в свои МК такую возможность - при наступлении WDT-таймаута не генерить тупо сброс, а активизировать прерывание, в котором ПО должно сделать какие-то проверки и, если всё ок, то сбросить WDT. Заметьте - сбросить внутри ISR!!!
И такие возможности есть и в других МК.

Так что оставьте свои религиозные убеждения "не употреблять некошерную пищу не сбрасывать WDT в прерываниях" - при себе. У нас тут вроде пока ещё светский форум

[Forger]

Вы безусловно что-ли генерите WDI?

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

Естественно так делать не надо.

Тогда мы говорим о немного разных вещах (не в первый раз кстати .
В вашем случае сброс можно формировать из без WDT - просто ждать ответа очередной задачи по таймауту средствами RTOS.
Не успела ответить - пишем событие в журнал, сбрасываем проц любым способом. Хотя это можно делать и через WDT.

Я же предпочитаю WDT использовать чуть иначе:
в сложных проектах помимо низкоприоритетной задачи с WWDT, я использую саму высокоприоритетную задачу,
в которой контроллируются остальные задачи по подобному принципу, как у вас, но уже средствами самой RTOS.
Такой же самый функционал в нормальных коммерческих RTOS встроен прямо в шедулер.

У нас тут вроде пока ещё светский форум

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

зы. самый лучший WDT - внешний, в идеале со своим источником питания.

[jcxz]

В вашем случае сброс можно формировать из без WDT - просто ждать ответа очередной задачи по таймауту средствами RTOS.
Не успела ответить - пишем событие в журнал, сбрасываем проц любым способом. Хотя это можно делать и через WDT.

Лучше это делать через WDT.
Во-первых: Зачем плодить лишние сущности (высокоприоритетная задача для контроля + низкоприоритетная) если можно всё сделать в одном месте?
Во-вторых: А если нужна длительная работа некоей задачи по длительной циклической обработке неких данных "как можно быстрее всё обработать, но реал-тайм не нужен - как всё закончили так закончили"? Тогда помещаем её на самый нижний приоритет и она там колбасит со 100%-ной загрузкой CPU. При этом отвечая на периодические запросы о живости от WDT-задачи.
Вот у меня был проект, где нужно было быстро излучить некий зондирующий импульс (УЗ), захватить эхо-отклик на него, затем сделать его тяжёлую обработку, а потом - отобразить данные (или отправить их в интерфейс). Я сделал излучение/захват на высоком приоритете, потом - понижение приоритета задачи до минимального, чуть выше Idle (чтоб не мешала остальным работающим в это время реал-тайм задачам), длительная обработка на минимальном приоритете, после завершения - опять повышение приоритета задачи. При этом некоторое время процессор МК был загружен на 100%, и если-б контролировал WDT в самой низкоприоритетной задаче, то не успел бы завершить тяжёлую обработку из-за его срабатывания.

Поэтому, "давая" остальным возможность втупую сбрасывать WDT в прерываниях, вы тем самым открываете им "ящик пандоры".

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

зы. самый лучший WDT - внешний, в идеале со своим источником питания.

Это не самый лучший - он просто обязателен. У меня во всех серьёзных проектах обязательно есть внешний WDT.
И тот алгоритм контроля, что я описал, он в реале работает с парой: внутренний WDT + внешний WDT. Стараюсь везде так и строить работу: внутренний WDT + внешний WDT. Естественно - время таймаута внутреннего при этом чуть меньше таймаута внешнего WDT.