Watchdog таймер Atmega16

[lkote68]

Уважаемые Коты Здравствуйте. Кто может что то подсказать по вопросу.
Предисловие: Разработал я контроллер температуры на DS18B20 на базе Аtmega 16.
Разные были глюки вроде я их победил и после последних неладов с работой при -20 все нормально
проработало 3 месяца.
Но вот начал сбоить один из контроллеров
в сети. Их в сети 9 штук по 485 опрашиваются. Под сбоем я имею ввиду что контроллер перестает
отвечать. По нажатию сброса все начинает работать нормально. У меня в коде стоит активизация
сторожевого таймера как его вносит редактор CodeVisionAVR.

// Watchdog Timer initialization
// Watchdog Timer Prescaler: OSC/2048k
#pragma optsize-
WDTCR=0x1F;
WDTCR=0x0F;
#ifdef _OPTIMIZE_SIZE_
#pragma optsize+
#endif

По идее если бы он зависал то он бы и сбрасывался. Кто может прокоментировать?

[andre_ksd]

Наиболее вероятно, что он зависает там, где есть команда wdr.

[lkote68]

Комманд #asm("wdr") там грядка целая. По этой команде сбрасывается счетчик WatchDoga. На этой комманде не зависает ОНА НЕОБХОДИМА.

[andre_ksd]

Прочитай внимательно и подумай. Эмоциональность это хорошо, но не всегда.

Пример:
i = 0;
while (i < 20)
{
asm volatile ("wdr");
// некая ошибка приводящая к тому
error_op();
i++;
}

...

void error_op()
{
//что неявно изменяется i
i = 0;
}

Как думаешь поможет тут сторожевой таймер, а?

[lkote68]

Не совсем понимаю. Ну зайдет в цикл Ну сбросит счетчик. Ну пусть потом 10 ошибок. Зависнул. Счетчик насчитал 2.1сек и сброс. Или поясни свою логику.

[andre_ksd]

Из этого цикла он НИКОГДА не выйдет, ни по условию, ни по сбросу от сторожевого таймера.
Потому, что каждый раз в цикле сторожевой таймер сбрасывается.
В цикле он зависнет!
Дошло?

[lkote68]

Извините В цикл вошел Таймер сбросил Потом по условию зависание Но вообще мысль поискать циклы Может где и вставил. Да и по условию там зависающих циклов вроде нет. Программа работает с августа месяца. Глюки были, но связаные с тем что при -20 приподнялся лог ноль и ресивер не принимал.

[andre_ksd]

Дело в том, что МК не "зависают" в вашем понимании. При наличии тактовой частоты, управляющий автомат извлекает, дешифрует и отдает команды на исполнение. Исключения бывают, но крайне редко, связаны, либо с повреждением ИМС, либо с потерей тактового сигнала.

МК "зависают" из-за ошибок в программе приводящих к "вечным циклам", нарушению стека... Команды сброса сторожевого таймера вставлют в код не "грядами", иначе от них толка нет, а с умом.
Например если есть ОС с кооперативной многозадачностью wdr должен находится ТОЛЬКО в диспетчере ядра, и больше нигде. Тогда если какой-либо из процессов "завис" более чем на n мс, произойдет аппаратный сброс. А если этот процесс постоянно wdr, wdr, wdr... то пока снаружи не сбросят, так и будет "висеть".

[lkote68]

А мысли как глянуть где он "висит" у Вас нет? Ведь работает 24ч считайте год. Программа на всех 9 шт одинакова....Это в промышленных подключился и видно где че не так.

[andre_ksd]

Строго говоря, судя по тому, то вы говорили ваша проблема не в ПО, а в деградации параметров элементов из-за температурных циклов, быть может грязь, или выпадение конденсата на платах.
Кроме того, уверены, что все компоненты имеют индустриальный/военный температурный диапазон?..
Нет алюминиевых электролитических конденсаторов?..
Истоники ЭМИ поблизости?..

[lkote68]

Да вряд ли деградация. Контроллеры стоят каждый в пластиковой практически герметичной коробке.
Компоненты импортные. Емкости Chang. Но там никаких потерь питание ровное как с батарейки. Более того
поменяли "материнку" "камень" остался тот же и все одно. Компоненты индустриального диапазона. Конденсат исключается по крайней мере при данной температуре. Это не часто но не понятно. Я же писал с середины января все тикает. Завис 5 дней назад. Сбросили и вот сегодня снова завис. Сегодня поменял прошивку в ней массив на 50 датчиков. А в прошлой был на 40 так сказать под обрез(8каналов по 5 датчиков).

[clawham]

очень часто зависания происходят по причине умирания тактовой!!!!и именно изза температурной деградации...и не только кварца а и генератора как такового...
поставьте в тело основного цикла фишку моргания светодиодом....дождитесь зависания и посмотрите моргает ли во время "повисания" или нет....и так на каждую функцию...можно при входе в функцию выставлять на какой-то свободный порт 7-мибитный номер функции в которую вошли а 8-й бит будет признаком начало процедуры или уже в конце перед выходом из этой функции - тогда и увидите где стопорится...потом переделаете в функции после каждого оператора выводить флаг начало выполнения оператора №х конец выполнения оператора №х ...и снова таки дождавшись зависона на выходе МК будете иметь НОМЕР оператора вызывающего зависание
ну методов отладки подобной лабуды миллион....
другой фокус в том что я уверен - номер процедуры всегда будет разным ибо умирает или тактовый или срывается стек....а этого уже найти очень сложно....и порою нереально...

[systemmind]

У меня несколько другая проблема касательно сторожевого таймера. Сделал загрузчик, со сторожевым таймером. МК mega1281. Если во время прошивки он завис, таймер срабатывает и загрузка начинается заново. После загрузки программа загрузчика делает JMP 0 и начинает выполнение загруженная программа-приложение. Проблема в следующем: если сторожевой таймер не срабатывает, то программа-приложение начинает работать нормально. Но если сторожевой таймер срабатывает, то несмотря на успешную загрузку программы-приложения после JMP 0 она уже не работает. Как будто вообще теряется фиг знает где. И начинает работать только после аппаратного сброса.

Тоже самое сделал для МК mega128 и на нем никаких проблем нет! В чем могут быть различия между сбросами по вочдогу меги1281 и меги128 ?