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

[Forger]

Как поможет тот пример, что Вы привели, восстановить работу?

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

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

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

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

[Den64]

Вы в упор меня не слышите. WDT не предназначен для устранения последствий программных косяков!

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

Произошла непредвиденная ситуация (любая, не ошибка софта.

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

[Forger]

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

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

WDT хорош против железных неполадок

Алилуйя!!!

я только за, я не против.

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

[Den64]

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

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

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

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

[Forger]

С чего Вы это взяли. Вы меня не слышите, но чьи то слова мне приписываете.

Ваши слова?

Ну вот как защитит WDT если, я просто запущу ещё один процесс который будет сбрасывать таймер допустим раз в секунду?

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

В приведённом примере я не знаю что с задачей, там софтовая моя ошибка. ... Просто для примера.

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

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

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

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

[Den64]

Ваши слова?

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

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

?


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

[Forger]

Вытесняющая многозадачность.

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

Код

void someTask(...)
{
  while (true) {}
}

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

Задача зависла или завершилась и не работает и не кому не мешает, и не грузит на 100% наверняка.

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

Но ваши способности удалённо читать "мысли" микроконтроллера поражают.

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

[Den64]

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

Код

void someTask(...)
{
  while (true) {}
}

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

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

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

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

[Forger]

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

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

[Den64]

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

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

[jcxz]

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

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

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

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

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

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

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

[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 - внешний, в идеале со своим источником питания.