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

Бывает что процессы зависают из-за ошибки алгоритма, но остальные работают. Всё управляется, обмены по интерфейсам идут, а результат не обновляется.
Сторожевой таймер ИМХО адекватно защищает только от железных зависаний. Т.е от грязи в питании, или остановки тактового генератора.
Разумное решение, на мой взгляд, это сбрасывать таймер в планировщике задач. Можно думаю и в отдельном процессе с самым низким приоритетом(если приоритеты конечно есть). Например все важные процессы устанавливают каждый свой флажок, а один из процессов изредка влючается и проверяет флаги. Если не все установлены то не сбрасывает таймер, а если все то сбрасывает все флаги и таймер.

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

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

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


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

watchdog контролирует не задачу, а процессор - если вдруг он повис, то собачка его аппаратно перезагрузит.
А все остальные задачи пусть контролируют время своей работы по какому-нибудь таймеру, и если надо, перезапускают или сбрасывают зависшую часть.

Я сначала обнулял его только в idle задаче, как правило такая есть в любой ос. Но заметил, что в редких случаях, при интенсивном обмене данными через некий порт микроконтроллера, собака не обнуляется. Добавили сброс и в функции обмена. Ну, а вообще, пришла идея, что сбрасывать можно в возникающих прерываниях. Как правило в ОС есть макросы для выхода из прерывания, которые выполняют перепланирование процессов, так вот, в этим макросы, по идее, и можно добавить сброс. Ну а так, на мой взгляд, зависит от структуры программы. Если более приоритетные задачи захватят управление, то idle может не получить управления. Соответственно, собака сбросит процессор.


Во! Интересная идея! +1!

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

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

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

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


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

В любом нормальном CPU сторожевой таймер имеет т. н. "оконный" принцип работы, т. е. сбрасывать его нужно не позже и не раньше заранее настроенного времени.
Это - очень удобный и полезный механизм.
Я использую его очень просто - создаю отдельную задачу, которая сбрасывает WDT через строго заданные интервалы времени (разумеется, допускается определенная погрешность).
Задача эта имеет самый низкий приоритет, фактически на уровне приоритета задачи Idle.
Как тут уже было сказано выше - WDT нужен для борьбы с зависаниями CPU, точнее, "заклиниваем" любой из задач.
Фактически, WDT я использую для неожиданных выходов уровня загрузки CPU до 100%.
Если код спроектирован достаточно грамотно, то этого никогда не произойдет, но в ответственных приложениях WDT - обязательная вещь.

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

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

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

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

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

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

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

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


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

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




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

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


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

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



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

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

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

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



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

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

А если по теме. Произошла непредвиденная ситуация (любая, не ошибка софта. Это я для примера писал), не работает один процесс. Как поможет тот пример, что Вы привели, восстановить работу?

Вы в упор меня не слышите! Повторюсь: WDT не предназначен для борьбы с последствиями банальных программных косяков!

WDT нужно настраивать на максимально допустимый интервал, за который программа не успеет наделать "делов".
В вашем примере - задача, которая может тупить (загружает проц. на 100%) слишком долго (намного дольше допустимого времени реакции системы на сбой), то эту задачу нужно дробить. А WDT тут уж не поможет.

На практике WDT я настраиваю на интервал максимально допустимой реакции на внешнее воздействие, на которое система не отреагировав вовремя, наделает печальных последствий.
В моих случаях - никогда не более 50..100 мс, обычно - намного меньше.

Если в системе есть задачи, которые могут быть загружены на 100% дольше, чем, скажем, один системный такт, то такой задаче всегда назначается минимальный (фоновый приоритет).
WDT тогда придется назначить приоритет выше. И то, если эта задача не работает в внешней аппаратной обвзякой (тупая числодробилка).
Но пока что, к счастью, мне всегда удавалось избежать подобных случаев :D

Это Вы не слышите.

я полностью согласен. WDT хорош против железных неполадок. я только за, я не против.

Я все прекрасно слышу: вы спрашиваете про то, как с помощью WDT исправить то, что исправляется совсем иначе.

Алилуйя!!!

Тогда к чему был заводить этот разговор про кривую задачу, зависающую на полсек?

С чего Вы это взяли. Вы меня не слышите, но чьи то слова мне приписываете. В приведённом примере я не знаю что с задачей, там софтовая моя ошибка. Ждать её сутками с отладчиком мне лень, разбираться тоже. Это не критично, что там зависает. Сейчас работает, зависнет перезагружу, мне не лень. Просто для примера.


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

Ваши слова?

"Допустим" тут не годится - допустимый период срабатывания WDT выбирается не с потолка. Выше я указал как это рассчитать.



WDT тут бесполезен. Это решается совсем иначе.
Однако, если речь идет про некий проект, собранном для себя лично на коленке, то разумеется никто не мешает применять WDT самым необычным способом )))


Мой пример, решает эту проблему на 100%, а не некоторой вероятностью. Главное условие - задача, где сбрасывается WDT, должна быть с самым низким приоритетом.
Тогда зависание любой задачи (100% загрузка проца) вызовет срабатывание WDT.

Если же нужно бороться с мервыми задачами (не грузит проц, но и не реагирует), то это делается не через WDT.
В проектах, где такое возможно, эта проблема решается совсем иначе.
Вы правильно сказали, что WDT нужен для борьбы последствиями аппаратных сбоев.
А то, что предлагает ТС, делать через WDT, делается программно и гораздо эффективнее.

Как мои слова связаны с

?


Вытесняющая многозадачность. Задача зависла или завершилась и не работает и не кому не мешает, и не грузит на 100% наверняка. Хотя точно не знаю, не принципиально и не интересно. Но ваши способности удалённо читать "мысли" микроконтроллера поражают.

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

Такая задача позволит выполнится любой другой задаче с бОльшим приоритетом, но меньшим приоритетом - ни разу.
Именно поэтому я помещаю сброс WDT только в одном месте - в фоне задач (не прерываний!), причем, в самой низкоприоритетной задаче.


Зависшася задача, которая не потребляет ресурсов - это задача, которая ждет некого внешнего события: семафор, сообщение.
Если этого события нет, то это задача тут ни при чем, искать нужно того, что не прислал нужного сообщения. Такие ошибки не решит никакой WDT.
Другой же случай: задача зависла (например, бесконечно полит некий флажок или крутится в бесконечном цикле), то такая задача загружает проц на 100%.
Такая ситуация сама по себе не возникает, но мое решение с WDT с ней борется на все 100%.
Ибо в реальном устройстве, которое, например, управляет внешней силой, подобные зависания могут привести к печальным последствиям.
И потому способ борьбы должен быть максимально аппаратным, вплоть до установки внешнего WDT, который сбрасывается точно также, но уже дерганием ножки проца в такой же самой низкоприоритетной задаче.

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

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

Мысли в кавычках.

Квант времени работает ТОЛЬКО для задач с равным приоритетом, он всегда измеряется в периодах системного таймера, в котором вызывается шедулер.
Это квант (slice) дает возможность работать другим задачам с РАВНЫМ приоритетом.
В остальном - все то же самое: все низкоприоритные задачи ждут, пока им не достанется чуток процессорного времени.
По крайней мере так сделано во всех ОСях, которые поддерживают time slice.
Подобная штука категорически необходима для проектов, где ВСЕ задачи имеют равный приоритет.

Согласен. Опять башка не варит, был не прав... Теперь буду знать.

В прерываниях нельзя, в задачах ОС получается - тоже, ведь чем они отличаются от прерываний? - да почти ничем. Да ещё вдруг они станут "работать впустую" - ай-яй-яй - опять нехорошо! Вобщем - засада сплошная.
Где-ж тогда его сбрасывать коли в задачах и в ISR нельзя? Вообще не сбрасывать? Или только православный суперцикл - наше всё?


Да ужж... любят в рассее как всегда бороться с кощуницами...
Чем же так не угодили прерывания-то? Так не угодили, что лучше уж зависнуть, но ни-ни к WDT!!?

PS: Сбрасывать можно везде. Если с умом подходить. И опираться на алгоритм работы задачи и здравый смысл, а не на религиозные убеждения...


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

О, про WWDT я и забыл, а когда видел, путал с AWD, где задается окно ADC. Выходит, 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/

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

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


"На каждую хитрую гайку - найдется свой болт с резьбой"...
Вот Вам выдержка из 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 в прерываниях" - при себе. У нас тут вроде пока ещё светский форум

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

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

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

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

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

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


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


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

У всех свое понятие "лучше".

У меня это было сделано в одном модуле LifeGuard (сущность "по-вашему"), в котором крутятся две задачи. Его реализация зависят от проекта. Простейшие содержат лишь задачу с WWDT.


Достаточно сделать ей приоритет равным или ниже задачи с WWDT, но тогда там нужно ручками обеспечивать гарантию ее независаемости.
Однако, я всегда стараюсь строить "числовые" задачи так, чтобы они не грузили ядро на 100%.

Увы, не всем .... обратите внимание на название этого раздела: "В помощь начинающему";)
Наверняка среди читателей этой темы найдутся те, кто до сих пор грешит суперлупом и там же постоянно сбрасывает WDT