Перейти к содержанию
    

Сторожевой таймер!...

defunct

И всё же...

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

кстати если есть разница в поведении программы как переброс питания или срабатывания wdt - reset

можно попробывать понять в чем дело ( в смысле прога или ап глюки)...

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

 

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

Любопытно что и наши изделия и "чужие" висли одинаковым образом. :)

Изменено пользователем SasaVitebsk

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Любопытно что и наши изделия и "чужие" висли одинаковым образом. :)

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...