Размер программы в ATmega324P превысил 15 kB и с некоторых пор попытки запрограммировать fuse WDTON безуспешны: программа не стартует. С незапрограммированным все нормально работает. Скорее всего случается таймаут WDT на полпути к main. C такой ситуацией столкнулся впервые и прошу подсказать как ее грамотно преодолеть в IAR? Как получить доступ к коду инициализации, чтобы одной из первых инструкций вставить обращение к переинициализации WDT?

Вам надо определить в проекте функцию __low_level_init(). Посмотрите в документации ее описание и пример.

Насколько я понял, для решения задачи нужно создать проект библиотеки на основе стандартной CLIB, внести туда изменения (в __low_level_init()) и скомпилировать эту "свою" библиотеку. Далее эту свою библиотеку подключить к проекту. Странно, но редактор в проекте библиотеки ругается на // комменты, /* а такие */ воспринимает нормально. Это баг?
И что же теперь, по каждому чиху перекомпилировать стандартные либы? Других способов видимо нет?

Поняли неправильно. В Вашем файле с функцией main определяете функцию __low_level_init() в которой отключаете сторожевой таймер на время инициализации. Далее настраиваете свое приложение и включаете сторожевой таймер.
Конкретно с IAR для AVR не работал, но идеология у IAR общая. Для MSP430 делаю именно так.
Если функция не определена, то ничего не делается. Если определена, то вызывается до main. Обратите внимание на возвращаемое значение 1 или 0, в зависимости от которого идет инициализация сегментов памяти.
Лучше всего почитать документацию на компилятор для деталей.

Где вы нашли такое в документации?? Просто добавьте в свой проект функцию Если проект на С++, то функцию надо объявить с extern "C"

Редактор ругается или все же компилятор? Посмотрите в настройках проекта раздел C/C++ compiler -> Language. Там надо выбрать Allow IAR extensions.
Дело в том, что коментарии '//' - это из С++, в стандартном С89 таких комментариев нет.

Достаточно просто вдумчиво читать документацию.

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

Инициализационные код в IAR-вских библиотеках достаточно быстрый. Врядли он тянет на срабатывание WD. Скорее всего вы на С++ наделали классов определённых глобально и это их конструкторы работают. В них тоже wdr натыкать надо. Ну и, как уже писали, в __low_level_init() задать корректные значения для WD. Мне кажется, что программа, ловящая WDR уже на инициализации, с такими параметрами WD будет ловить его и в ходе работы.

Зачем было включать WDTON на фузах? Задача решается гораздо проще, если этот фуз не включать, а watch dog включить программно в cамом начале main(). Тогда, каким бы ни был продолжительным по времени setup(), watch dog работает нормально. А на сетапе прога не застрянет - он умными людьми писан .
P.S. Пока я не прочла эту тему, то думала, что все делают так, как я.

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

Нет, писано на С. Проблема вылезла именно с увеличением объема кода. Времени не хватало, пришлось писать быстро, возможно в ущерб качеству, но др выхода не было. По-моему, там пришлось даже компилятору инициализировать несколько переменных в EEPROM. А это время... Вот WDT и успел сработать. По памяти в ATmega324P по сбросу WDT устанавливается на 16ms (мин значение). ИМХО, вполне реально преодолеть...

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

Перед смертью не надышишься - если у вас память и регистры сбоят, то watch dog вам не поможет. Даже лучше будет, если такой дерьмовый проц не запустится, чем если он начнет что-то делать с такими регистрами и памятью. Дурью, господа, маетесь. стараясь запустить проц, который не может пройти setup без ошибок.

Давайте не будем столь категорично оценивать друг друга. Ведь зачем-то этот фуз вставили в процессор? Значит есть такие задачи, где WDT должен быть включен при исполнении стартапа.

Очень возможно, что такие задачи существуют. Но в данной теме обсуждается проблема раннего срабатывания watch dog'а. Т.е. синдром как раз таков, который происходит от неудачно установленной фузы. Отсюда и ответ - не ставить эту фузу, раз уж такая проблема возникла. А не решать проблему через ухо - мы де setup перепишем и туда через строчку __watchdog_reset() понавтыкаем.

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

Возможно. Назовешь, хоть одну? Типа отлаживались без WD медленно и печально а потом fuse включили (главное не забыть) и отдали в серию? Но тут startup ни причем.... У меня до сих пор фантазии как-то не хватило и включаю WD ручками, если включаю. Если вдруг должен будет включен во время startup, то там не только проинициализирую, но и включу. Позицию разработчиков некоторых контроллеров, которые по reset всегда WD включают и дают потом возможность один раз отключить или перенастроить я еще понимаю, но зачем разновариантность вводить-то?

Нет. Но это не означает, что их не существует. Даже ты допускаешь возможность их существования.Ну, наличие неиспользуемой кем-то функции для тех, кто ее использует все же лучше чем ее отсутствие. Я не использую прерывание по окончанию записи во флеш - писать в Лигу Наций или пусть остается - не мешает ведь?

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

Вы не понимаете видимо сути моего высказывания. Процессор хороший и память и регистры - всё ок. Но помеха может сбить что угодно и когда угодно (и даже во время startup). К Вашему сведению, помеха обычно просто искажает данные в ячейках памяти а не сами ячейки. И я включаю WDT фьюзм, ибо мои приборы и проекты используются не только в гражданских целях.

Не катит . Потом "из-за помех" точно-также будет болтаться в WD "бесконечно". Получаем неработоспособную вещь и без разницы, где она там "бесконечно болтается" , главное, что по любому НЕ РАБОТАЕТ.


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



Еще раз и помедленнее, что такое "искажает сами ячейки"?


Круто! Несчастные потребители получают "приборы" выживающие только за счет WD. А туда еще добавить много много еще сбитых ячеек памяти НЕ приведут к срабатыванию WD, но к "глюкам".... А как-же вообще разработчики на других плаформах НЕ имеющих дивного фьюза, как класс, разрабатывают свои изделия?

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

Кусок сбоящего дерьма и после долей миллисекунды-секунды проведенных в startup ДОЛЖЕН будет часами-годами работать и тогда уж за это время гарантированно "включит чего-нить такое, от чего станет кисло" и WD не тявкнет даже. Да и за время срабатывания WD сошедший с ума по независящим от него причинам контроллер напахать может очень даже не мало - чай не арифмометр и команды быстро может выдавать.

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

У нас есть "модифицированный рашпиль" для проверки. Не видел такой электроники, которая бы не превращалась в "кусок сбоящего дерьма" при проверках.
Я просто за то, что если есть возможность уменьшить потери, то лучше это сделать.
А вот из-за Вашей точки зрения Чернобыль и взорвался!

Нет, я только для Ляньюньганя (Тяньваня) и Куданкулама оборудование делал. Не на AVR и категорически без WD вообще, бо перезапуск в произвольный момент времени сам по себе Ж.....

В очередной раз констатирую, что я с AVR почти не знаком, но поскольку в корневом сообщении вопрос про ATmega324P, то можно ли в качестве ликбеза мне пояснить: как WDT влияет на "прорыв" в основную программу, если в AVR (как я понимаю) программа исполняется из Flash, а не из SRAM? Т.е. срабатывание WDT в стартапе ориентировано только на тот исчезающе малый случай наличия "плавающих" уровней во Flash, я правильно понимаю?


Ну и тоже свой случай из жизни. Шкафы управления двумя газовыми котлами, теплоснабжением, ГВС и вентиляцией. Входные сигналы от токовых датчиков термопреобразователей и дискретные с преобразованием сигналов переменного напряжения 220В и постоянного 24В. Регулирует температуру отопления, горячего водоснабжения и вентиляции. Контроллеры имеют WDT, который не просто RESET для CPU делает, а полностью снимает питание с блоков контроллера. При запуске котельной в результате аварийной ситуации полопались и расплавились металлопластиковые трубы отопления, котлы перегрелись аж до 160°C (может и выше, но не удалось зарегистрировать т.к. датчики были до +150°C), в помещении котельной температура была ненамного меньше. "Спасло" от взрыва, что система пожаротушения не была заполнена водой. Представьте попадание холодной водички на перегретые котлы!
В результате "разбора полетов" выяснилось, что завис АЦП, с помощью которого измеряются токи с преобразователей температуры. В результате контроллер считал, что у него температура теплоносителя низкая и котлы аварийно отключать вовсе не требуется. Т.е. контроллер-то работал нормально, но входные данные не проверялись на "валидность", а другой цепи защиты от перегрева котлов изначально задействовано не было.
Этот оффтопик я к тому, что надежность не определяется только лишь наличием/отсутствием/использованием WDT. Надежность это задача комплексная и решается/определяется всеми средствами/компонентами системы.

1) WDT на прорыв в основную программу не влияет никак, на прорыв куда-бы то ни было влияют внешние факторы. Нейтрино пролетело, разряд статики или еще что-нибудь. В результате WDT может оказаться не запущенным.
2) А при чем тут место нахождения программы? Даже если считать флэш "железной", код передается в АЛУ по каким-то шинам, через регистры, которые могут исказить данные. Что говорить - в АВР производителем ограничено изменение периода частоты между соседними периодами, хотя он "статический". Это нежный прибор, ненамного лучше хорошо знакомого Вам MSP430, в котором нет даже триггера Шмитта на входе сброса.

А насчет комплекса факторов, влияющих на надежность - полностью согласен.
Ради Бога, не считайте меня апологетом теории надежности типа "Дохтура", я самый отъявленный практик
Я делаю дешевые поделки, которые, тем не менее, должны работать в сложных условиях ЭМС. Или не работать. Но не вредить

Никогда не стартовал с отключенной собакой. Никогда ни одна поделка на АВР не работала без собаки. И не будет. Наверное, вопрос религиозный все-таки.

Ничем другим объяснить это действительно невозможно .

Это значит, что помеха искажает содержимое ячейки памяти (был 0 стал 1 и наоборот), а сама ячейка _физически_ остаётся исправной.
Ну и упёртый народ Я вот не пойму даже с чем Вы спорите?
С включенным через fuse wdt контроллер не проводит фактически времени без неусыпного взгляда собаки, а с отключенным проводит.
Мало, но проводит. Да шанс мал словить грабли за это время, но он ЕСТЬ. Так зачем же сознательно закладывать это шанс?
И, к вопросу: "А если нет встроенного wdt?" - мой ответ: ставить однозначно внешний! И это не религиозные соображения.
Не следует пренебрегать благами прогресса, мы ведь с вами не аскеты и не секта.
В конце концов, мы давно не считаем на логарифмической линейке, а используем по большей части компьютер

Но тем не менее пытаетесь рассказывать, как "надо трясти пальму" . WD это есть последний. САМЫЙ последний шанс за живучесть. Причем далеко не всегда однозначно безболезненно применимый и всенепременно пользоваться этим шансом на первых микросекундах полета совершенно не обязательно. Как впрочем, как и вообще пользоваться WD - меня, например, ну очень расстроит переферийный контроллер втихаря перезапустившийся по собственному WD и забывший все, что ему приказывали делать.

Надо флаг состояния "амнезия" завести или ногу какую-л подергать... Иначе описанная Вами ситуация напоминает профессиональное хождение по канату...

Да, флаг 'амнезия' для тех у кого контроллер сходит с ума даже не пройдя инициализацию это сильный ход .
Это решается много естественнее - в этом случае контролем работоспособности периферийных занимается центральный контроллер, он-же их сбрасывает, он-же приводит их в надлежащее состояние после сброса. И никаких собственных WD у периферийных, за полной их ненадобностью, не задействуется.

А может дело в том, что сам setup слишком долог? Может быть поместить стринги и массивы/структуры констант во flash, чтобы разгрузить setup от копирования большого объема данных из flash в SRAM? Тогда setup быстрее работать станет и успеет отработать за время стандартного watchdog'а.

Об этом с самого начала ветки толкуют. Причем и топикстартер это уже понял. Странно, что вы упоминание функции __low_level_init в начале топика или пропустили или не поинтересовались ее описанием в IAR.

Это не пальма... А тот случай когда контроллер один одинёшенек или основной. Речь ведь об этом изначально идёт. А Вы приводите доводы из другой оперы. Для большинства посетителей этого форума, как мне кажется, ситуация с наличием периферийного контроллера не столь частое явление (у меня соотоношение 1:20). Исходя из этого, и из личного опыта я бы рекомендовал не пренебрегать wdt, bod, настоящим генератором вместо кварцевого резонатор и прочими средствами, повышающими надёжность функционирования. Имеешь wdt - так пользуйся грамотно. Вот и всё, что я хочу сказать на сей счёт.
С рождеством Вас!

Это не доводы это просто один из самых очевидных примеров, когда встроенный WD не нужен. Случаи, когда и одиночный контроллер пусть лучше явно "повесится", чем забудет, что делал и начнет что-то делать заново/другое тем самым дезинформируя пользователя, тоже имеют место быть. У меня срабатывание WD практически никогда не приводит к молчаливому выходу на рабочий режим - это прежде всего индикация моей железной или софтовой халтуры. Выходить или нет на рабочий режим после срабатывания WD и вообще инициализировать или нет WD у меня обычно находится в конфигурации изделия.

Я рад, что заставил Вас задуматься об использовании WD, а то раньше вообще было без WD хоть ложись и помирай а если вдруг его нет, то "ставить однозначно внешний".

Вынужден согласиться. И если честно, считаю применение WD с последующим принятием ответственных решений делом крайне опасным в большинстве случаев. Бывает очень сложно программно проанализировать ВСЕ аварийные ситуации и принять такие решения.
Вот бы еще пару примеров рассмотреть по данному поводу. Особенно когда небезосновательно принимается решение - РАБОТАТЬ!!! )))

Ну, причина сброса может быть обработана.
Разница наших подходов в общем-то понятна - у меня контроллер моторчика или нескольких помп/клапанов, а у Вас коммуникационный контроллер, обвешанный защищенными интерфейсами.