[Abcde 0]

Сейчас период таймаута выбран 0,5 сек, обнуление счетчика сторожевого таймера происходит в одной задаче РТОС, которая начинает выполняться только через 1 секунду после подачи питания (такая особенность). Получается сторожевой таймер срабатывает раньше…

Где должен обнуляться счетчик сторожевого таймера? Сейчас он обнуляется в одной из задач РТОС, почти безусловно, т.е. контролируется только правильность работы этой задачи. Как контролировать остальные, особенно если они взаимосвязанные (ждут результатов работы других задач)?

Или задачи во время своего выполнения сами должны анализировать себя и сигнализировать выше, но если РТОС вытесняющая, то задача может прерваться и анализ оказаться неполным или не быть готовым к моменту принятия решения о сбросе по сторожевому таймеру. Как тут быть?

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

Спасибо!

 

[Den64 0]

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

Сторожевой таймер ИМХО адекватно защищает только от железных зависаний. Т.е от грязи в питании, или остановки тактового генератора.

Разумное решение, на мой взгляд, это сбрасывать таймер в планировщике задач. Можно думаю и в отдельном процессе с самым низким приоритетом(если приоритеты конечно есть). Например все важные процессы устанавливают каждый свой флажок, а один из процессов изредка влючается и проверяет флаги. Если не все установлены то не сбрасывает таймер, а если все то сбрасывает все флаги и таймер.

 

[jcxz 181]

Где должен обнуляться счетчик сторожевого таймера? Сейчас он обнуляется в одной из задач РТОС, почти безусловно, т.е. контролируется только правильность работы этой задачи. Как контролировать остальные, особенно если они взаимосвязанные (ждут результатов работы других задач)?

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

[Baser 3]

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

 

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

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

 

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

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

[HardEgor 61]

Где должен обнуляться счетчик сторожевого таймера? Сейчас он обнуляется в одной из задач РТОС, почти безусловно, т.е. контролируется только правильность работы этой задачи. Как контролировать остальные, особенно если они взаимосвязанные (ждут результатов работы других задач)?

watchdog контролирует не задачу, а процессор - если вдруг он повис, то собачка его аппаратно перезагрузит.

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

 

[haker_fox 59]

Где должен обнуляться счетчик сторожевого таймера?

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

 

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

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

[jcxz 181]

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

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

Все задачи построены в виде циклов ожидания/обработки события, схематически:

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

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

Регулярные построены точно так же - без разницы.

Контролирующая, после установки состояния "проверка состояния задачи TASK_ID...", перестаёт генерить WDI до того момента, пока контролируемая задача не вызовет ILive().

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

[Arlleex 130]

Контролирующая, после установки состояния "проверка состояния задачи TASK_ID...", перестаёт генерить WDI до того момента, пока контролируемая задача не вызовет ILive().

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

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

[jcxz 181]

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

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

 

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

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

[Forger 17]

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

В любом нормальном CPU сторожевой таймер имеет т. н. "оконный" принцип работы, т. е. сбрасывать его нужно не позже и не раньше заранее настроенного времени.

Это - очень удобный и полезный механизм.

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

Задача эта имеет самый низкий приоритет, фактически на уровне приоритета задачи Idle.

Как тут уже было сказано выше - WDT нужен для борьбы с зависаниями CPU, точнее, "заклиниваем" любой из задач.

Фактически, WDT я использую для неожиданных выходов уровня загрузки CPU до 100%.

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

 

Однако, использовать его нужно правильно, иначе проку от него никакого не будет:

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

В этих случаях вся полезность WDT напрочь "убивается"! :smile3046:

 

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

[ViKo 1]

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

 

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

 

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

 

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

 

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

[Forger 17]

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

(С) "Век живи - век учись!" ;)

Например, в STM-ках есть WWDT - Window WDT...

Вообще, в идеале, WDT должен тактироваться от собственного независимого генератора (в нормальных МК есть даже несколько разных WDT, в т.ч. "аналоговых").

При схеме, которую я описал выше, любой сбой системной частоты, от которой тактируется системный таймер ОС, вызовет несвоевременный сброс WDT, что вызовет всегда сброс проца.

Т. е. оконный WDT позволяет еще и бороться со сбоями тактовой частоты (банально коснулись пальцем выводов кварца), т. е. WDT "контролирует" связь приложения с реальным временем.

 

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

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

Приложение давно висит, но данные снаружи сыпятся, вызывают прерывания, те уже семафорят (будят) задачи и тем самым безусловно вызывают планировщик, а тут сбрасывается WDT ... короче, в такой схеме WDT вообще бесполезен!

 

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

4. Сбрасывать сторожевой таймер в прерываниях ....

 

 

 

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

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

Проект может меняться как угодно, а WDT - как работал так и должен работает. Ему все это должно быть "до лампочки". В противном случае проку от такого WDT не будет.

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

[Den64 0]

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

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

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

 

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

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

[Forger 17]

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

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

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

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

 

 

 

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

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

WDT создан лишь как дополнение к существующим методам защиты, но не их замена.

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

 

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

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

 

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

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

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

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

 

Непонятно.

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

 

 

 

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

Да хоть 500 тыщ строк кода, сути это не меняет.

Угробить функционал WDT очень просто - достаточно лишь сбрасывать его где надо и не надо ;)

[Den64 0]

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

...

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

...

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

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

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

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