Сторожевой таймер!..., быть ему ...или не быть? Опции

[MakFatum]

Здравствуйте!
Два вопроса по сторожевому таймеру:

1. Обязательным (или желательным) требованием при написании программы является включение этого таймера?..
и чем руководствоваться при расставлении #asm("wdr") в программе?
расставлять так часто чтобы обнуление WDT происходило через промежутки времени ГАРАНТИРОВАНО меньшие чем время переполнения таймера WDT???
...или, если я пользуюсь VMlab он советует, куда поставить команду сброса обращать внимание на его инструкции??
2.
Мне непонятен код, который генерирует CVAVR при включении в визарде сторожевого таймера
что он означает? (строки с #)

Код

#pragma optsize-
WDTCR=0x1D;
WDTCR=0x0D;
#ifdef _OPTIMIZE_SIZE_
#pragma optsize+
#endif

Спасибо...

Сообщение отредактировал MakFatum - Apr 18 2006, 09:17

[ALexx]

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

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

VMLab сообщает Вам о том, что ИМЕННО В ЭТОМ МЕСТЕ может произойти сброс, соответственно Вы должны ставить данную инструкцию раньше.
И вообще полагайтесь на здрвый смысл и логику работы программы, а не на сообщения симулятора (IMHO может подвести)


Это директивы компилятору, запрещающие оному оптимизировать код находящийся между ними("-" -отключение оптимизации, "+" - включение)

[WHALE]

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

[BVU]

wdr лучше всего ставить в коде,вызываемом в цикле,
...

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

[era]

Это выдержка скопирована из FAQ от fido7.ru.embedded, ИМХО так и надо.

Вопрос: Как выбрать момент сброса WDT?
Ответ: Обычно WDT требуют периода обращения к ним в течение 0,03-3 с. Причём внешние WDT имеют период более одной секунды. Встроенные в МК WDT могут настраиваться на различные периоды при помощи внутренних регистров контроллера. В общем случае, период сброса WDT должен всегда быть меньше его таймаута на генерацию сигнала "Сброс".
Программа обычно состоит из процедур обработки прерываний и фоновой программы. Сбрасывать WDT в процедуре прерывания крайне не рекомендуется, поскольку вполне может случиться так, что основная программа по каким-то причинам перестала выполняться, а процедура прерывания (например, от внутреннего таймера) продолжает работать. Сброс WDT в процедуре прерывания можно сделать лишь в том случае, если время выполнения этой процедуры может превысить таймаут самого WDT. В этом случае перед сбросом WDT неплохо проверить флаги, контролирующие работу фоновой программы. Например, можно ввести счётчик, который будет уменьшаться в прерывании, и при достижении значения "0" WDT перестанет сбрасываться. Основная программа будет устанавливать этот счётчик как признак её работы. Но такая ситуация скорее исключение, чем правило.
Обычно WDT сбрасывается в самом внешнем цикле программы (например, функция main(), если программа написана на языке Си). При необходимости перед сбросом WDT выполняется ряд контрольных проверок.
Во многих системах в том или ином виде используется отсчёт реального времени. Для этой цели обычно используется один из внутренних таймеров МК, переполнение которого вызывает прерывание. Для контроля работоспособности таймера реального времени в основной программе перед сбросом WDT выполняется проверка флага, установленного в прерывании от таймера:
disable_interrupt();
if (timer_int_flag) {
timer_int_flag = 0;
reset_wdt();
}
enable_interrupt();
Если в системе используются другие циклические прерывания, то в проверку перед сбросом WDT можно внести и их флаги.

[Proton]

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

[Kovrov]

А что такое внешний WDT?
если рассуждать лог-ки, нужно ему через интревалы времени сигнал сброса давать чтоли?

[iosifk]

А что такое внешний WDT?
если рассуждать лог-ки, нужно ему через интревалы времени сигнал сброса давать чтоли?

Давайте обобщим лог-ки.
Есть такое понятие надежность и достоверность. Надежность - сделает или сгорит. Достоверность - выполнит или не выполнит.
Как проверить, что выполнит?
А так-же как и у операционника. Стабильность его коэфф. усиления сравнивыется с более стабильным параметром - сопротивлением резистора Обратной связи. В случае микроконтроллера, процесс, выполняемый микроконтроллером, сравнивается с процессом в WDT. Тоесть по времени исполнения. Выполнился процесс до срабатывания WDT, значит правильно.
Чем внешний WDT лучше? А тем, что этот чип имеет меньше транзисторов внутри, следовательно он более надежный, чем микроконтроллер.
А где делать обработку - там, где надо проверять время работы программы. Но необходимо учесть прерывания.
Ну а более конкретно Вам уже написали выше.

[BVU]

А что такое внешний WDT?
если рассуждать лог-ки, нужно ему через интревалы времени сигнал сброса давать чтоли?

По всей видимости именно так:

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

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

[Igor26]

А что такое внешний WDT?
если рассуждать лог-ки, нужно ему через интревалы времени сигнал сброса давать чтоли?

Да. Например MAX691. Если на ее входе WDI пропадают импульсы, то через пол секунды она формирует импульс сброса. Импульсы ей нужно подавать от контроллера, ессно.

[Rst7]

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

[plan]

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

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

[_artem_]

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

[defunct]

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

Внешний WDT для MK с встроенным hardware WDT это просто расточительство. Кроме того, внешний WDT требует дополнительных линий управления со стороны МК и надлежащей программной реализации, что может привести вместо повышения, наоборот к снижению надежности.
По поводу того, что у вас возникали какие-то проблемы с встроенным WDT, это вероятнее всего связано с неправильным использованием последнего либо с неудачно выбранным местом в программе для исполнения команды wdr.

[vet]

defunct
И всё же...
Бывают случаи - завис AVR, включенный встроенный ватчдог его не сбрасывает. Приходится ставить внешний.

[defunct]

defunct
И всё же...
Бывают случаи - завис AVR, включенный встроенный ватчдог его не сбрасывает. Приходится ставить внешний.

Бывают всякие случаи. Бывают случаи, когда отслаиваются дорожки ПП. либо что-то не контачит, либо наоборот что-то замыкает. Либо наводятся помехи и внешний девайс (WDT) при этом добавит только доп. нестабильность.

WDT в AVR это отдельный девайс, который тактируется отдельным RC генератором. Завис AVR - WDT продолжает работать unless WDT не проинициализирован. Чтобы не возникало ситуаций, описанных Вами, необходимо обязательно использовать BOD, и грамотно инициализировать и сбрасывать WDT.

[Kovrov]

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

[vaivai]

Я имею дело с сигнализациями (DSC,Spectra) - очень редко,но виснут.
Интересно,что иногда виснет как бы часть устройства - все функции работают а какая то нет - помогает переключение питания.

[SasaVitebsk]

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

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

Приведу пример из своей практики. В облтелекоме стояли изделия подключенные к маршрутизатору. Круглосуточная работа. 10 моих на atmega8515 и 10 "чужих" на базе PIC. Свои я вылизовал несколько месяцев. В результате на PIC висли ~ ч/з 1.5 суток, а мои ~ ч/з 10 суток. Но всё равно висли! Вдумчивое применение WDT привело к полному отсутствию зависаний. (т.е. они были, но устройство с ними справлялось). И в настоящий момент времени используются только мои изделия.

Насчёт вдумчивого тестирования. Работа идёт с маршрутизаторами CISCO. Разработанное изделие очень непростое плюс логика его работы изменяется в зависимости от 69 регистров (битовые!) Играет роль входящий поток. Последняя найденная и устранённая ошибка возникала с вероятностью одна на 20 переданных мегабайт инфы. Никто не даст подключенный маршрутизатор для тестирования твоего копеечного оборудования. И тебя туда не пустят. Эмулировали работу, эмулировали ошибочные ситуации и т.п. Да и вообще при возникновении виса 1 раз в неделю как его вычислить???
Любопытно что и наши изделия и "чужие" висли одинаковым образом.

Сообщение отредактировал SasaVitebsk - Apr 22 2006, 20:42

[plan]

Приведу пример из своей практики. В облтелекоме стояли изделия подключенные к маршрутизатору. Круглосуточная работа. 10 моих на atmega8515 и 10 "чужих" на базе PIC. Свои я вылизовал несколько месяцев. В результате на PIC висли ~ ч/з 1.5 суток, а мои ~ ч/з 10 суток. Но всё равно висли! Вдумчивое применение WDT привело к полному отсутствию зависаний. (т.е. они были, но устройство с ними справлялось). И в настоящий момент времени используются только мои изделия.
Насчёт вдумчивого тестирования. Работа идёт с маршрутизаторами CISCO. Разработанное изделие очень непростое плюс логика его работы изменяется в зависимости от 69 регистров (битовые!) Играет роль входящий поток. Последняя найденная и устранённая ошибка возникала с вероятностью одна на 20 переданных мегабайт инфы. Никто не даст подключенный маршрутизатор для тестирования твоего копеечного оборудования. И тебя туда не пустят. Эмулировали работу, эмулировали ошибочные ситуации и т.п. Да и вообще при возникновении виса 1 раз в неделю как его вычислить???
Любопытно что и наши изделия и "чужие" висли одинаковым образом.

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

[SasaVitebsk]

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

Так я не отвергаю ваше предыдущее замечание, а полностью его подтверждаю. Чем более качественно прописано всё, тем надёжнее работает изделие. Очень важно также правильно выбрать протоколы и методики съёма/соединений и т.п. При более менее серийном изделии очень важным является полное тестирование (также после каждого изменения). А WDT, я лично, подключаю на самом последнем завершающем этапе. Иначе будет как в Windows ошибка работы одной проги благополучно устраняется корекцией в другом блоке, - а с виду всё великолепно работает!

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

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

[tag]

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

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

А что может быть источником аппаратного зависания?

[rezident]

А что может быть источником аппаратного зависания?

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