WatchDog Timer Сторожевой таймер в AVR

[Starichok51]

а как ты думаешь, while (1) когда закончится?

[ARV]

[uquote="Starichok51",url="/forum/viewtopic.php?p=3641908#p3641908"]а как ты думаешь, while (1) когда закончится?[/uquote]
Когда WDT сработает

[YS]

абсолютно правильный /верный и программно и железно ?

Идейно да. Сброс по WDT аналогичен сбросу кнопкой ресета.

[bortnik27]

Подскажите Attiny13A от attiny85 сильно отличается в программном плане, или только объемом памяти? Можно ли перепаять на место 85ой 13ую в digispark и прошить, будет ли нормально работать watchdog и прерывания?

[akl]

Отличается и очень сильно
-тактирование
-адресами прерываний
-аппаратной поддержкой интерфейсов

[Starichok51]

[uquote="ARV",url="/forum/viewtopic.php?p=3641911#p3641911"][uquote="Starichok51",url="/forum/viewtopic.php?p=3641908#p3641908"]а как ты думаешь, while (1) когда закончится?[/uquote]
Когда WDT сработает [/uquote]там у него перед
while (1)
стоит
wdt_enable(0);
и когда, по твоему, WDT сработает, если он отключен этой строкой программы?

[ARV]

и месяца не прошло

[Kalisnik]

Необходимо сделать защиту цепи от зависания МК. Т.к. если МК зависнет с высоким уровнем на ноге, часть схемы может сгореть. Отсюда вижу 2 варианта:
1. Делать защиту по таймеру 555 на периферии (ограничить время протекания тока). Но это лишние элементы на плате.
2. Использовать как способ защиты WatchDog.

Если делать защиту на WatchDog, хотелось бы быть уверенным, что WatchDog сработает в 100% случаях. Отсюда вопрос: насколько механизм WatchDog надежен?

[ARV]

WatchDog надежен ровно в той степени, в какой надежна любая периферия МК.

[parovoZZ]

насколько механизм WatchDog надежен?

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

[ARV]

вачдог инертен

поясните

[Kalisnik]

[uquote="ARV",url="/forum/viewtopic.php?p=4040750#p4040750"]WatchDog надежен ровно в той степени, в какой надежна любая периферия МК.[/uquote]
Насколько надежна периферия МК?

[ARV]

параметры надежности некоторых моделей AVR можно найти среди технической документации на сайте производителя. во всяком случае я когда-то их там находил.

[LEVV2006]

Всем привет! И с новым годом!
Для тех кто проснулся и протрезвел Вопрос - задачка под 1 января!

Хочу к проекту подкрутить сторожевой таймер что бы перестраховаться на случай зависания МК.
И вот столкнулся с доселе неизвестной мне проблемой! Но давайте об аномалии поподробнее.

Среда: atmel studio 7 МК: ATtiny841 (datasheet) Фьюзы: H:D5, L:E2, Ext: FF

Загрузчика нет. Заливаю прошивку сразу по SPI.

Программа уже написана и отлажена осталось прикрутить WatchDog. Чтобы всю портянку не выкладывать приведу схематичны кусок кода.

Код: Выделить всё

#include <avr/wdt.h>  //подключаем библиотек WatchDog
int main(void)
{
	USART_Init();
	printf("MiniPrimaryClock\n"); //При перезагрузке приветствие в Com порт
	//Здесь инициализация портов
	wdt_enable(WDTO_2S); //Включаем WatchDog на 2с

	while (1)
	{
		if (PinVolt&Pin_Volt) //Проверяем Пин. Если лог 1 то
		{
			wdt_reset();//сбрасываем таймер
		}
	}

Код простой но вызывает странную реакцию.
Когда лог. 1 на пине то МК стартует нормально. И в СОМ порте пишется приветствие "MiniPrimaryClock (с переводом строки)". Все проходит штатно.
Стоит изменить состояние пина на лог. 0 то через 2с МК перезагружается. И в СОМ порт начинает лететь одно и тоже "MiniPrimaryClockMiniPrimaryClockMiniPrimaryClockMiniPrimaryClockMiniPrimaryClock.......и тд. (Перевода строки нет)".
Как будто МК в постоянной и циклической перезагрузке.
И самое странное в этой истории это то что МК не реагирует на ФИЗИЧЕСКОЕ нажатие на кнопку ресет! МК якобы перезагружается но прям сразу начинает писать белиберду.
Помогает вывести МК из такого состояния только физическое отключение питания.

Я уже не знаю куда дальше копать...... Кто ни будь знает в чем может быть причина?

[VNS]

[uquote="LEVV2006",url="/forum/viewtopic.php?p=4151796#p4151796"]Как будто МК в постоянной и циклической перезагрузке.[/uquote]
Так и есть. И это не зависит от конкретного МК. Просто в алгоритме неверно прописана функция очистки флага сторожевого таймера. То есть не в том месте алгоритма где это должно быть (как я подозреваю). Или вообще эта функция отсутствует в алгоритме, а она должна быть в самом начале алгоритма....
Как я понял (но могу и ошибаться, так как не владею языком Си), поправьте если не прав. У Вас после подачи питания выполняется вначале отправка сообщения по UART . Затем выполняется конфигурация портов и только при условии значения на выводе пина (при лог 0), осуществляется включение сторожевого таймера с соответствующими настройками. Верно? Если так, то Вы и получаете такой вот эффект.
Чтобы убрать данный эффект, После старта МК Вам необходимо прописать функцию очистки флага сторожевого таймера и тогда повторный сброс МК не будет происходить. Вернее будет, но только после 2 сек. (согласно настройке интервала отсчёта сторожевого таймера) если на соответствующем пине будет продолжать висеть лог 0.

[LEVV2006]

Пробовал вначале писать и wdt_reset(); и wdt_disable(); не помогает.

Вообще я предполагал что после отработки WatchDog происходит общий сброс МК (как после нажатия кнопки Ресет). (На других популярных МК так и происходит.

[VNS]

[uquote="LEVV2006",url="/forum/viewtopic.php?p=4151924#p4151924"]Вообще я предполагал что после отработки WatchDog происходит общий сброс МК (как после нажатия кнопки Ресет).[/uquote]
Да, так и есть происходит сброс МК… и вот в начале вашего алгоритма, Вам необходимо выключит сторожевой таймер. Так как он у Вас уже включен и флаг прерывания не сброшен, что и вызывает повторный сброс после перезагрузки МК. Вам при загрузке МК необходимо прописать процедуру выключения сторожевого таймера. Для включения/выключения сторожевого таймера используются два разряда регистра WDTCR, это WDE и WDTOE. Разряд WDE отвечает за включения/отключения сторожевого таймера. То есть если установлен в 1 – таймер включен, если 0 – таймер выключен. Разряд WDTOE служит как защитой для непреднамеренного отключения сторожевого таймера. То есть сброс разряда WDE произойдёт после того как в разряд WDTOE будет записана 1. Данный разряд (WDTOE) автоматически сбрасывается после 4 машинных цикла в ноль.
Если короче, то в начале Вашего алгоритма нужно прописать такую процедуру: соответствующее число записать в регистр WDTCR. Что будет соответствовать выключению сторожевого таймера. Как это прописывается на Си я не знаю.

[LEVV2006]

[uquote="VNS",url="/forum/viewtopic.php?p=4151943#p4151943"]Вам необходимо выключит сторожевой таймер.[/uquote]
Вас я понял, но в распространенных МК такого не требуется.
Кроме того я уже писал выше что пробовал так делать.
Самой первой инструкцией писал wdt_disable();

Попробую тогда еще сделать в ручную на уровне регистров.

[VNS]

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

Добавлено after 8 minutes 12 seconds:
Посмотрел даташит... Да, с регистрами я напутал :

1.png

(41.6 КБ) 295 скачиваний

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

[LEVV2006]

[uquote="VNS",url="/forum/viewtopic.php?p=4151957#p4151957"]Но вот то, что его необходимо отключить, мысль правильная. [/uquote]
Мысль то возможно правильная но не очевидная если честно.....
Таймеры работают по кругу... досчитают до определенного момента, произведут событие и сбросятся. Продолжат считать опять от нуля. (Это из моего опыта с другими МК. Там все работает без лишних отключений/переключений).

Вообще МК этот 841 очень странный. Точнее урезанный в каких то неожиданных местах. (Я первый раз сейчас программирую этот МК и брал его из за размеров)

Что касается Сторожевого таймера.
Если честно я почти отчаялся за вчерашний вечер и сегодняшний день
Но ваши мысли и рассуждения были правильные!
Помогла вот такая вставка в самом начале
asm volatile("wdr\n\t");
WDTCSR=(0<<WDE)|(1<<WDP2)|(1<<WDP1)|(1<<WDP0);

И кстати даташит тоже не очень четко все это дело описывает......

Большое спасибо что помогли с этим чудом разобраться!