Watchdog что это в телевизоре

Обновлено: 14.01.2025

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

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

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

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

Несмотря на это, я всё же, взвесив все "за" и "против", всё же решил ещё раз попытать счастья и выложить пару уроков (пока пару, а там посмотрим, как дело пойдёт) по данным микроконтроллерам.

Что же всё-таки сподвигло меня на данный шаг?

Во-вторых, новый хозяин данного семейства контроллеров Microchip, включил эти контроллеры в свою среду разработки MPLAB X, что позволит нам теперь обойтись сразу на два семейства одной средой разработки.

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

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

Вот и настало время наконец-то восполнить данный пробел.

Watchdog Timer (WDT) – это сторожевой таймер (а если перевести дословно, "сторожевой пёс"), который представляет собой аппаратно-реализованную схему контроля над зависанием системы. Это таймер, который периодически сбрасывается контролируемой системой. Если вдруг сброса не произошло за определённый интервал времени после предыдущего сброса данного таймера, то происходит принудительная перезагрузка системы (в нашем случае микроконтроллера).

В каких конкретных случаях мы можем применить данный таймер?

Например, мы ждём ответа от какой-нибудь шины (например I2C или ещё какой-то) в виде отслеживания состояния определённого бита регистра. И вдруг произойдёт кратковременное отсоединение провода этой шины. После этого скорей всего произойдёт зависание программы, так как в шине будет сбой, и даже если что-то после и придёт от присоединённого узла, то мы вряд ли уже это отследим изменением состояния бита. Желательно, чтобы после какого-то таймаута система перезагрузилась. Тут-то и приходит нам на помощь WDT, который установлен на определённый интервал. Команду на перезагрузку сторожевого таймера мы расположим в нашем коде после того, как мы дождёмся отклика от шины. А если мы так его и не дождёмся, то мы не дойдём до команды перезагрузки WDT и через заветный интервал времени система будет перезагружена. После этого произойдёт заново инициализация шины и всё будет опять работать нормально.

Понятно, что данная ситуация подходит только для случая, когда нам приходится не слишком долго ждать отклика от устройств, то есть именно тогда, когда у нас существует какой-то непрерывный процесс, в котором есть возможность ситуации сбоя. Таких примеров можно придумать много, поэтому Watchdog Timer очень много где применяется.

При работе с таймером в нашем коде мы не будем напрямую работать с его регистрами, так как там ещё надо проделывать очень много различных подготовительных мероприятий. Для этого существует отличная библиотека wdt.h, которая находится в стандартном комплекте для AVR и не требует дополнительного подключения откуда-то. Но тем не менее о том, как именно устроен сторожевой таймер в контроллере ATMega328, которым мы и будем сегодня пользоваться, мы всё же поговорим.

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

А вот это диаграмма сброса контроллера по истечении интервала времени

Кроме того, что мы можем сбросить сторожевой таймер где-то в коде, мы можем также и отследить окончание интервала времени по прерыванию, которое надо включить отдельно.

WDT, как и было указано выше, работает от отдельного генератора.

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

Давайте посмотрим блок-схему WDT

На рисунке мы видим, что после генератора на 128 килогерц, сигнал проходит на предделитель, который содержит 10 различных выходов с различным коэффициентом деления. Предделитель настраивается с помощью битов WDP3:WDP0 регистра WDTCSR. Таким образом, интервал времени работы WDT лежит в диапазоне от 15 милисекунд до 8 секунд.

Также мы видим, что с помощью бита WDIE мы можем разрешить прерывания от сторожевого таймера и затем попасть в обработчик, отслеживая состояние бита WDIF. Включается таймер с помощью бита WDE.

Вот он – управляющий регистр сторожевого таймера

Хоть мы уже и говорили о битах данного регистра выше, но всё же давайте все их рассмотрим подробно, их не так и много, так как у таймера всего один регистр

WDIF (Watchdog Interrupt Flag): флаг прерывания. Устанавливается в 1 в случае истечения интервала времени таймера. Сбрасывается аппаратно.

WDIE (Watchdog Interrupt Enable): бит разрешения прерываний от таймера. если установлен в 1, то прерывания разрешены, если в 0 – запрещены.

Существует таблица зависимости от состояния бетов WDE, WDIE, а также фьюза WDTON

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

WDP2:WDP0 (Watchdog Timer Prescaler): биты, устанавливающие коэффициент деления предделителя сторожевого таймера.

Вот таблица возможных комбинаций данных битов

Здесь также даны сами интервалы в единицах времени.

WDCE (Watchdog Change Enable): бит изменения, который должен быть предварительно включен перед тем, как мы соберёмся внести изменения в предделитель с целью изменения коэффициента деления либо для отключения таймера путём занесения в бит WDE значения 0. Сбрасывается аппаратно после четырех тактов.

WDE (Watchdog System Reset Enable): бит включения таймера, а вернее бит включения режима перезагрузки системы по истечению интервала времени таймера WDT.

Ну вот, я думаю и всё насчёт теории по сторожевому таймеру. Если что-то пропустил, то исправим это в процессе сочинения кода.

Код наш выполнять будет следующие задачи.

У нас, помимо WDT, будет также работать ещё таймер TIM1, данный таймер будет работать по совпадению, следовательно в обработчик прерываний от него мы будем попадать через определённое время периодично. В обработчике таймера мы будем периодично включать 10 ножек различных портов, а состояние их на какой-то момент мы будем определять по светодиодам, которые мы к ним подключим. Вернее, мы подключим светодиодную планку с 10-ю светодиодами, не забывая конечно о токоограничивающих резисторах, которые я на всякий случай подключил на 680 Ом, при этом светодиоды светятся вполне ярко. В начале программы мы запустим наш сторожевой таймер WDT и зададим ему определённый интервал времени срабатывания. В процедуре обработки прерываний от таймера 1 мы будем своевременно сбрасывать сторожевой таймер, поэтому, если всё у нас будет нормально с ходом программы, то система у нас будет работать и не перезагрузится.

А для того, чтобы проверить, перезагрузится ли наш WDT по истечению интервала, мы сэмулируем ситуацию, что наш таймер перестанет работать. Для этого мы подключим кнопку к контакту INT0 и обработаем от неё внешнее прерывание, в обработчике которого мы запретим прерывания от нашего таймера. Светодиоды, соответственно перестанут бежать, тем самым сигнализируя нам о том, что наш таймер 1 "сломался". Поэтому сторожевой таймер не перезагрузится, тем самым перезагрузит нашу систему и весь процесс у нас начнётся заново.

В качестве контроллера для урока мы возьмём контролер ATMega328P, расположенный на плате Arduino Nano, к которой подключим обычный USB-программатор через разъём ISP. Вставим нашу плату в макетную плату, подведём к ножке PD2 (INT0) кнопку, а также от ножек D3-D12 (ножки портов PD3:PD7, PB0:PB4) подключим аноды светодиодов планки, а катоды через токоограничивающие резисторы подключим к общему проводу

Проект мы создадим в среде программирования MPLAB X, с которой мы постоянно работаем с микроконтроллерами PIC, так как у данных контроллеров владелец один и тот же, то нет смысла использовать несколько сред для разработки. Как установить данную среду разработки, показано здесь.

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

Запустим среду программирования MPLAB X и запустим создание проекта с помощью следующей кнопки

Выберем "Standalone Project" и идём далее

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

На следующем шаге в качестве программатора выберем Simulator и идём далее

На следующем шаге выберем компилятор и идём дальше

Дадим имя нашему проекту и жмём "Finish"

В дереве проекта в ветке Source Files добавим новый файл main.c с помощью контекстного меню на данной ветке

Исправим имя файла и нажмём "Finish"

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

А пока создадим ещё заголовочный файл main.h аналогичным образом, только выбрав в контекстном меню на ветке "Header Files" и затем выбрав соответствующий пункт

Для нормального функционирования функции задержки зайдём в свойства проекта и откроем там настройки компилятора, в которых выберем настройку оптимизации

Оставим уровень оптимизации 0 и установим чекбокс на пункте Debug

Назначение этих составных частей станет понятно из описания алгоритма функционирования WDT:

цитата:
What is a watchdog timer?
A "watchdog" is a piece of hardware that counts down a timer.
If the timer reaches zero, it hard-resets the computer (like pushing
the reset button). So the software must reset this timer too avoid
rebooting.
The good thing is: If the computer hangs, the software
can't reset the timer and it (should) reboot automatically.

Текущая версия v.0.2: 8rdawdt-0.2.tar.bz2 (увы, только под юниксы )
---
Обсудить эту и другие статьи/записи с моей персональной страницы можно в соответствующей ветке конференции.

Подпишитесь на наш канал в Яндекс.Дзен или telegram-канал @overclockers_news - это удобные способы следить за новыми материалами на сайте. С картинками, расширенными описаниями и без рекламы.

Сторожевой таймер - очень важный механизм системы Linux. Его цель - контролировать работу системы. В случае блокировки или сбоя он может вовремя перезапустить компьютер (в зависимости от стратегии настройки) и собирать аварийные дампы.

watchdog，Как подсказывает название, Сторожевая собака. Это означает, что есть объект, за которым наблюдают, и программа, которая наблюдает за ним.

Будь то сторожевой таймер ядра или сторожевой таймер пользовательского пространства, основная идея такова:
1. Предположим, что состояние объекта может указывать на работоспособность системы (например, количество прерываний, например метка времени / dev / watchdog);
2. Запустите сторожевую программу и регулярно наблюдайте за этим объектом (запускается внутренними или внешними часами), чтобы определить, исправна ли система, и предпринять соответствующие действия.

Watchdog имеет несколько различных механизмов реализации.Недавно я повозился с принципами работы различных механизмов в компании, провел эксперименты на лабораторных машинах и суммировал следующие два механизма:
1. kernel watchdog
2. Userland watchdog

Ниже мы соответственно описываем их механизмы.

цель сторожевого таймера ядра

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

Так называемая блокировка относится к определенной части кода ядра, занимающей центральный процессор. В тяжелых случаях зависания вся система перестает отвечать. Блокировка имеет несколько характеристик:

Во-первых, только код ядра может вызвать блокировку, Поскольку пользовательский код может быть вытеснен, невозможно сформировать блокировку (есть только одно исключение, то есть процесс в реальном времени с приоритетом SCHED_FIFO 99, даже в пользовательском режиме, может сделать поток ядра [watchdog / x] неспособным захватить CPU. мягкая блокировка)
Во-вторых, код ядра должен находиться в состоянии выключенного вытеснения, поскольку Linux является ядром с вытеснением, а вытеснение запрещено только в определенных областях кода (таких как спин-блокировка), и в этих областях кода может образоваться блокировка.

Блокировка делится на два типа: мягкая блокировка и жесткая блокировка. Разница между ними состоит в том, что жесткая блокировка происходит, когда процессор экранирует прерывания. Мягкая блокировка - это ситуация, когда один ЦП всегда занят (на прерывания все еще можно реагировать).

Здесь мы сначала представим NMI.

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

Прерывания делятся на маскируемые прерывания и немаскируемые прерывания.

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

Но NMI другой, даже если прерывание отключено, на него можно ответить. Условиями запуска NMI обычно являются аппаратные ошибки, такие как ошибки ECC. Однако NMI также предоставляет нам механизм для выполнения некоторых аварийных операций, таких как паника ядра, через обработчик прерывания, даже если системное прерывание закрывается по ошибке.

Здесь задействованы 3 вещи: поток ядра, прерывание часов, прерывание NMI (немаскируемое прерывание).

У этих трех вещей разные приоритеты: поток ядра systemctl start softdog.service

Когда мы запускаем сервис softdog, будут выполнены следующие операции:
1. modprobe softdog // Если softdog не загружен в ядре, загружаем его
2. watchdog -c /etc/softdog.conf

По умолчанию программа сторожевого таймера создает устройство (устройство таймера) с именем / dev / watchdog1 через softdog.ko и периодически записывает на него (используется для обновления метки времени).

Softdog, находящийся в ядре, будет имитировать устройство таймера (моделирование посредством прерывания часов) и выполнять соответствующую процедуру обработки прерывания.Цель этой процедуры - проверить, не истек ли таймер (т.е. / dev / watchdog1). Если истекло время, выполните соответствующее действие (по умолчанию - паника).

Умные дети заметили проблему: если система не может реагировать на прерывание часов, не работает ли softdog?

Бинго, это действительно так. Если система не может ответить на прерывание (например, прерывание отключено), программа моделирования таймера в softdog.ko не может работать и, естественно, не может ответить. Но в этом случае сторожевой таймер NMI, представленный ранее, может работать.

Кроме того, мы можем просмотреть номер устройства, соответствующий сторожевому таймеру, через / proc / devices

Как видите, softdog зарегистрировал номер устройства с основным номером 252.

hardware watchdog

После разговора о softdog давайте поговорим об аппаратном сторожевом таймере.

Аппаратный сторожевой таймер, поскольку он аппаратный, он не должен зависеть от ОС. Реализация на разных устройствах разная. В нашей лаборатории есть два пути достижения:

Реализовано через BMC.
Реализовано через iTCO.

Разрешите рассказать о реализации BMC.

BMC, также называемый материнским контроллером основной платы, представляет собой фоновый контроллер, встроенный в материнскую плату и не зависящий от ЦП и памяти. Система может быть включена и выключена BMC. В настоящее время обычной практикой является использование инструмента ipmi для отправки команд на BMC для достижения цели получения системной информации. Например, получить температуру процессора, статус, включение, выключение системы.

Есть два способа запустить таймер на BMC:

Первый - включить таймер ОС при входе в интерфейс настроек BIOS (конкретное место настройки зависит от модели материнской платы).

После настройки система запустит аппаратный таймер (аппаратный таймер, управляемый BMC). Без запуска аппаратного сторожевого таймера он автоматически отключится и запустит сброс системы.

Второй способ - запустить службу ipmidog. После установки watchdog rpm выполните следующие операции для запуска службы ipmidog:
- systemctl start ipmidog

Чтобы понять этот механизм, давайте посмотрим, что делает системная служба ipmidog:

Здесь он проверит, существует ли / dev / watchdog0 (не совсем понятно, что это значит, многие люди в Интернете говорят, что / dev / watchdog0 и / dev / watchdog указывают на одно и то же устройство, несмотря ни на что). В противном случае загрузится ipmi_watchdog.ko. Этот модуль связывается с BMC через IPMI. Затем запустите сторожевой таймер.

Мы можем просмотреть конкретную информацию о таймере через ipmitool:

Помните, что ipmi watchdog не может вызвать панику, он может только перезагрузить машину.

Теперь поговорим о iTCO

Поскольку у iTCO меньше актуальной информации, я кратко ее представлю.

iTCO - это метод таймера, предоставляемый самой Intel. С точки зрения конфигурации, нет необходимости перезагружать компьютер для входа в BIOS. Он настраивает аппаратный таймер с помощью драйвера под названием iTCO_wdt. Он может обеспечивать механизм, аналогичный сторожевому таймеру ipmi, и не требует дополнительной аппаратной поддержки, такой как BMC.

unknown_nmi_panic

Это немного не по теме, unknown_nmi_panic - это параметр ядра, этот параметр не имеет прямого отношения к сторожевому таймеру, но для отладки времени простоя системы хороша паника удаленного триггера. Итак, краткое введение.

Прежде всего, почему здесь упоминается параметр ядра unknown_nmi_panic?

Когда система не работает (зависает), согласно тому, что мы говорили ранее, у нас есть сторожевой таймер ядра для обнаружения мягкой блокировки, сторожевой таймер NMI для обнаружения жесткой блокировки и сторожевой таймер для определения состояния приостановки системы в пространстве пользователя. Но это не распространяется на все зависания системы. Кроме того, при использовании softdog для мониторинга планирования пользовательских процессов это зависит от того, может ли система реагировать на прерывания; при использовании аппаратного сторожевого таймера для мониторинга планирования пользовательских процессов, когда происходит зависание, систему можно перезапустить только без запуска паники.

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

Один из механизмов - использование NMI для запуска.

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

На материнской плате супермикро BMC может отправлять неизвестный NMI на контроллер прерываний. Это может быть достигнуто следующими способами (не все BMC поддерживают этот способ):

Здесь следует отметить, что некоторое другое программное обеспечение для мониторинга также будет использовать неизвестный NMI (включить пользовательский обработчик прерываний NMI), поэтому при использовании этого программного обеспечения / конфигураций необходимо отключить unknown_nmi_panic.

Среди них вышеупомянутый сторожевой таймер NMI является таким механизмом.Когда nmi_watchdog установлен в 1, unknown_nmi_panic должен быть отключен. (Я экспериментировал с некоторыми моделями и не обнаружил вышеупомянутых конфликтов, но поскольку это официальная информация на сайте, ради страховки я все же пытаюсь отключить его).

Кроме того, существует программа Oprofile, которая также использует NMI в качестве программного обеспечения для мониторинга системы.При использовании Oprofile также необходимо отключить unknown_nmi_panic.

Магический ключ SysRq

Напоследок еще одно отступление, упомянем волшебный ключ SysRq.

Когда мы включаем параметр ядра sysrq (установлен в 1), мы можем управлять запуском системы или паникой с помощью Alt + SysRq + , где:
1. Alt + SysRq + c запускает панику
2. Alt + SysRq + b запускает перезагрузку.

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

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

Watchdog расшифровывается как сторожевой таймер. Основная его функция - перезапуск системы в определённых случаях, таких как: зависание системы, повышенная температура, пропадание связи и т.д. Бывает аппаратный, программный и программно-аппаратный.

Меня заинтересовала прежде всего такая функция, как перезапускать систему при отсутствии связи с роутером. Почему прежде всего именно эта функция?

У меня часто отключают свет в квартире, а при подаче питания вновь часто отваливается HomeBridge на микроконтроллере Raspberry Pi 3 (далее малинка). Лечится это перезагрузкой самой малинки. Причина до конца не выяснена, но думаю мой роутер запускается позже чем сама малинка. Проведя эксперимент с выключением роутера во время работы малинки, я убедился что HomeBridge перестает функционировать. Вы можете проверить сами и написать в комментариях как решили данную проблему. Может быть проблема могла решиться заданием статического IP на самой малинке, но я это не проверял.

На малинке установлен образ с Node 10 по статье нашего коллеги. Малинка подключена к роутеру с помощью кабеля и её IP зарезервирован как статический адрес на роутере.

Так вот для решения проблем с пропаданием питания, благодаря советам нашего сообщества, я решил установить Watchdog. Как готовое решение я взял статью, которая полностью соответствовала моим запросам.

Заходим на малинку по SSH и устанавливаем демон Watchdog командой:

Далее делаем бэкап конфигурационного файла, если что-то пойдет не так и для отказа от работы Watchdog, если нет больше необходимости.

Далееи редактируем файл конфигурации /etc/watchdog.conf

В файле конфигурации необходимо раскомментировать ниже приведенные строки и задать Ваши параметры

Теперь при отсутствии пинга 5 раз каждые 20 секунд (через 100. секунд) малинка будет перегружаться. Конечно интервал и количество пингов можно изменить в зависимости от задач, а так же при необходимо сменить IP на внешний (8.8.8.8 для примера) для проверки работоспособности интернета (хотя зачем это в моем случае).

Ложка дёгтя

Надо помнить, что при потере связи с указанным IP адресом малинка будет постоянно перегружаться и если Вы этого не хотите, то надо вернуть старый файл конфигурации (мы его специально сохраняли). Делается это командой

Я тестировал работу Watchdog , описанную в статье, отключая роутер на интервал более заданного и малинка перегружалась. При отключении роутера на меньшее время HomeBridge всё равно не запускался, так что Watchdog оказался бесполезен для решения конкретно моей задачи. Возможно что Watchdog контроля связи будет особенно полезен для тех кто использует Wi-Fi подключение. Как это повлияет на работоспособность малинки при длительном отсутствии связи (умер роутер) я не знаю. Рекомендую иметь рабочий бэкап прежде чем что либо устанавливать.

Как я уже писал выше Watchdog может перегружать малинку и по другим событиям, но это уже другая, не мене интересная тема., которую я продолжу изучать. Для желающих разобраться ниже ссылки на инструкции по Watchdog.

Прикольная картинка взята здесь

Мнение редакции

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

Читайте также: