А много ли данных у вас? Часто ли они обновляются? Долго ли хранятся?

Если не ошибаюсь, у некоторых контроллеров AVR перед тем как "собака" перезапустит контроллер, можно уйти в обработчик прерывания WDT. А там можно сохранить данные в ЕЕPROM, если конечно уверен в целостности данных.

Возможность использования WDT в качестве интервального таймера присутствует у ATtinyXXXX и usb, и у некоторых ATmega. Поэтому, чтобы не проколоться нужно справляться в DS на камень в разделе System Control and Reset

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

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

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

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

Подробнее>>

Если проц завис, то это значит что он находится в бесконечном цикле. Разве цикл помеха прерыванию?

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

http://avrprog.blogspot.ru/2013/03/watchdog.html

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Кстати. Поглядел структурную схему расширенного WDT и кое-что почитал.
Получается интересная хрень. Если разрешить одновременно прерывания и сброс контроллера WDIE и WDE, то пока включен WDIE сигнал сброса блокируется. Биты WDIE и WDIF автоматически сбрасываются при входе обработчик прерывания. После выхода из прерывания контроллер сбросится только тогда, когда WDIF опять включится, т.е. когда "собака гавкнет" второй раз. "Данный режим позволяет перед сбросом микроконтроллера сохранить различные критические переменные программы".

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

Вывод: кот иногда может быть кривым , а вот код нет.

Мдаааа, интересно получается.
Спасибки.. Буду курить...

Тогда возвращаемся к внешнему WDT, аппаратному или на ATtiny13, в которой не включено никаких прерываний и лишнего кода, RC таймер, аппаратно фьюзами включен WDT, никаких лишних переменных, никакого стека и зависать там нечему будет. При любом сбое программа вернется в начало. Ну и проверять работоспособность основного контроллера можно и по простому, по переключению ноги, и более изощренно, "общаясь" через UART.

Странно рабатает выход из сна по WDT (Тини13а).
WDT настроен только на прерывание. Сон - PowerDown.
Если код такой, появляются очень странные глюки:
SEI
SLEEP
CLI
Если сделать например так (добавить любую команду после SLEEP), то все работает нормально:
SEI
SLEEP
LDI R16,0
CLI

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

Коллеги возникла трудность в настройке сторожевого таймера а Atmega328P.
сброс должен осуществляться из прерывания таймера Timer1 вызываемого периодически 0.1с
Компилятор CVAVR. Код пробный, практически целиком сформирован CWAVR.
Делитель WDT устанавливал и больше и меньше, и с прерыванием WDT и без,
таймер T1 делал и 0.01с и 0.1с и 1с
пробую в протеусе, фьюз WDTON пробовал и установлен и нет,
Итог WDT из прерывания не сбрасывается, МК уходит в перезагруз,

но, если сброс #asm("wdr") поставить в бесконечном цикле то все работает,
и совсем без WDT тоже все работает, считаются участки времени на дисплее.
Что я сделал не так?

гдето у ардуинщиков читал что (почти дословно) "современные мк оставляют после сброса сторожевой таймер включенным на некоторое время для распознавания причины сброса , и если его не успеть выключить при старте программы МК будет вечно перегружаться". может это именно этот случай?

PS организовал отдельный таймер 0, в прерывании только сброс сторожевого таймера.
прерывание с периодом 3.75мС все работает хорошо, на единичку больше 3.89мС уже пошли пересбросы.
Такое впечатление что не прошли настройки делителя у сторожевого таймера, и от чего же он тактируется если по даташиту у него минимальный период 16мС

Или я вообще чтото не так делаю?

Вот мой код

#include <mega328p.h>
#include <alcd.h>
int s = 0; // переменная для хранения секунд
interrupt [TIM1_COMPA] void timer1_compa_isr(void)
{ s++; // увеличиваем переменную каждую секунду
if(s>99) {s=0;} // обнуляем после 99
#asm("wdr") //отсюда таймер не сбрасывается, происходит перезагрузка
TCNT1H=0x00 >> 8; TCNT1L=0x00 & 0xff; //обнуляем таймер
}

void main(void){
#pragma optsize-
CLKPR=0x80;CLKPR=0x00;
#ifdef _OPTIMIZE_SIZE_
#pragma optsize+
#endif

TCCR1A=0x00;TCCR1B=0x05;
TCNT1H=0x00;TCNT1L=0x00;
ICR1H=0x00;ICR1L=0x00;
OCR1AH=0x02;OCR1AL=0xD0; //0.1сек
OCR1BH=0x00;OCR1BL=0x00;
TIMSK1=0x02;
lcd_init(16);

#pragma optsize-
#asm("wdr")
WDTCSR=0x39; WDTCSR=0x29; // Watchdog Timer Prescaler: OSC/1024k
#ifdef _OPTIMIZE_SIZE_
#pragma optsize+
#endif
#asm("sei")

while (1) {
//#asm("wdr") //если коментирование убрать то все работает
lcd_gotoxy(0,0); //вывод в 0 координате X и Y
lcd_putchar(s/10+0x30);lcd_putchar(s%10+0x30); //вывод
}
}

Полный проект с протеусом прилагаю

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

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

Если бы Вы не пренебрегли пошаговой отладкой, то подобных вопросов и не задавали. Пошаговое выполнение - основное средство отладки программы.

Зачем Вам watchdog?

Я много думал. У меня есть подозрение, что при пробуждении МК, поскольку реакция AVR на прерывание занимает четыре такта, сразу начинает выполняться инструкция, стоящая после SLEEP, а прерывание вызывается на эти четыре такта позже. Если первая инструкция после SLEEP - запрет прерываний, получается ситуация, когда прерывания запрещаются в тот момент, когда происходит переход в обработчик прерывания. Может быть причина в этом.

Еще на стр. 13 даташита есть такая информация:

When the AVR exits from an interrupt, it will always return to the main program and execute one
more instruction before any pending interrupt is served.

Может быть это как-то связано.

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

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

я изначально настраиваю делитель собаки для пработы с периодом 8с (OSC/1024k)
а вызов прерывания для его сброса планировался с периодом 0.1с, на мой взгляд вполне достаточно ))

я привел код, это именно он и не работает, там ошибаться негде, почти весь код создан автоматически CW.
В начале программы как раз стоит сброс собаки и установка предделителя:
#pragma optsize-
#asm("wdr")
WDTCSR=0x39; WDTCSR=0x29; ......
Или всетаки не так??

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

Да пишет и как раз их я и читаю, я прекрасно понимаю что сброс произошел от переполнения WDT, я не понимаю почему это произошло раньше того как я его сбрасываю.
Регистр MCUSR тоже отразит переполнение WDT

Честно я не умею делать пошаговую отладку, у меня недостаточно опыта и я еще не разобрался как это делается,
точно такойже код прекрасно работает на mega8, визуально в протеусе видно что если не сбросить переполнение возникает через заданное время, а на mega328 это время не выдерживается, повторюсь у меня два подозрения
1. не программируется по какойто причине предделитель WDT. Потому что если поставить сброс в основном цикле или в специально созданном для этого прерывании с очень маленьким периодом 3.75мС то все работает
2. не правильно отрабатывается WDT в протеусе именно в этом камне, в наврядли конечно , скорее это моя ошибка.

Мне правда нужна помощь, помогите пож ))

electronik_tver, fuse-биты контроллера верно выставлены? Нет такого, что он, например, вместо 8 МГц работает на 1 МГц?

Да нет там ничего хитрого. Запускаете Вашу программу в симуляции и шагаете. Шагнули - поглядели состояние важных регистров, еще раз шагнули - еще посмотрели. Ну как же сразу то, сначала у Вас настройка предделителя генератора, потом таймеров, по факту еще в код встрояются скрытые команды, типа установка указателя стека и фиг знает чего еще там автокод делает. Но это по идее все мелочи, а вот функция lcd_init(16);, которая тоже стоит до настройки предделителя, возможно использует временные задержки.
Обязательно проверьте, что товарищ YS говорит.

Вот еще что, по поводу пошаговой отладки. Установите точку останова перед настройкой собаки. И поглядите сколько тактов тратит МК, прежде чем доберется до нее, если добирается конечно. Он же еще и время напишет, когда это происходит.

задумывалась работа контроллера от кварца 7.3728MHz (для UART), так и выставляю в протеусе
CLKDIV8=1, CKOUT=1, RSTDISBL=1, WDTON=0, BOOTRST=1, SKSEL=1111 (Ext Crystal 8MHz), BootLoaderSize=00, SUT-01.
Так?
Я весь проект выложил в первом своем сообщении, он маленький посмотрите пож настройки, я мог что-то очевидное пропустить.
Но визуально, когда таймер тикает через секунду, секунду и видно, когда 0.1 быстрее, когда 0.01 еще быстрее,
а вот переполнение явно на порядок быстрее чем 8 секунд, все тоже самое на mega8 видно визуально, 8 секунд так он и стоит и переполняется 8 секунд,

я скрин лога с протеуса выложил во втором сообщении, можно посмотреть, там со временем

да обещаю хотябы попробовать
а CVAVR позволяет пошаговую отладку делать?

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

Тут код то минимальный состоит из таймера, WDT и LCD и то создан автоматически, по идее ошибаться тут негде, посмотрите пож проект, я наверняка допустил какую нибудь школьную ошибку, я все рекомендации попробовал и до сих пор не знаю что я сделал не так )

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

Замените ка вот это TCCR1A=0x00; на вот это TCCR1A=1<<WGM12; Включится режим "CTC". Я тут вспомнил, что у меня протеус глючил и не хотел уходить в прерывание по совпадению OCR1A. А в режиме "СТС" все работало. Заодно таймер будет автоматически обнуляться, так что вот это чудо TCNT1H=0x00 >> 8; TCNT1L=0x00 & 0xff; //обнуляем таймер можно будет выкинуть.

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

кстате все что я пробовал заработало в железе, и 8сек и сброс из таймера.
спасибо огромное за участие,
видимо всетаки глючил протеус именно на этом камне и именно на собаке..