Здравствуйте, Уважаемые коллеги.

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

Кто сталкивался?

Спасибо.

Ну, почему же "не программное"?
Как вариант: Разрешается прерывание на каком-либо устройстве, а процедуры обработки этого прерывания не существует - забыли написать...

Обработчики прерываний на месте и в порядке.
Останавливается именно обработка главного цикла. При чём в разных местах.
Завтра буду осциллографом питание смотреть на предмет иголок....

Код покажите.
Если прерывание постоянно куда-то уводит PC, со стеком может быть непорядок.

"Останавливается" - Это просто пи-дец!!!
До тех пор пока Вы будете предполагать что процессор может как-то "ЗАВИСНУТЬ" вы никогда не найдёте ошибку в Вашем коде.
Попробуйте исходить из того что "зависнуть" процессор просто не может НИ-КО-ГДА .
Примите это как аксиому и ищите косяки в своём коде.
А если пишете на СИ - будьте готовы к тому, что придётся искать не только свои но и чужие КОСЯКИ!

Чем же так СИ провинился?

Видимо, в сравнении с ASM, где каждая строчка самовыстраданная)

Ну для AVR можно и на СИ каждую строку самовыстрадать.
Да и вполне разумно: код небольшой, в дальнейшем дешевле выйдет.

Вот сейчас вывел на LCD содержимое SP. Жду. Пока что светится 2301=0x8fd. При старте программы SP=0x8ff. Вход в main по CALL, так что пока что вроде норм... По наблюдениям отпишусь.

Спустя 6 часов работы зависло. SP=2301.

Код в студию, весь.

Снова, спустя 11 часов...
Прерывание на приём символа от UART работает - в обработчик вставил код для подсвечивания светодиода на время обработки прерывания.
Средняя загрузка ЦП обработчиком 0,22%, пиковая - 14%.
Передача не происходит в режиме ожидания.
От таймера прерывание тоже происходит (оно генерирует смещение на LCD, без него LCD потухнет).

zombi, насчёт "чужих косяков" - согласен. Уже были "чудеса"
в этой программе, пока не избавился от применения библиотечной ф-ции sprintf.
Пока она применялась в одном только месте - всё работало... как ещё в одно поставил - начались "чудеса".
Избавился от sprintf - и "чудеса" пропали...

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

Genadi Zawidowski, Код выкладывать смысла нет - слишком большой. Atmega занята на 72%. Всё равно столько смотреть не станете...

Ещё вот с WatchDog проблема... может подскажете...вот тема:
https://electronix.ru/forum/index.php?showtopic=140918

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

"Еще одно место" - прерывание? Какой компилятор используете? Это я к тому, что IAR использует два стека (один для возвратов и второй для данных), gcc использует один. sprintf() очень охочая до стека функция. Если используете gcc, то стек вам увеличивать уже некуда, возможно стоит пересмотреть алгоритм чтобы уменьшить занимаемую глобальными переменными память или хотя бы посмотреть, не затирается ли память сразу после глобальных переменных - это будет говорить о налезании стека на данные и разрушении содержимого стека. Если используете ИАР - можно попробовать увеличить один из стеков за счет другого.

Это совершенно бесполезная информация. Зависание произошло после вывода на LCD, и если оно стало результатом порчи стека Вы этого не увидите.
Для проверки целостности лучше заливать стек паттерном и проверять его содержимое.
Как залить - тема тут была ранее.
Если используете WatchDog, посмотрите как часто Вы его передергиваете. Я бы порекомендовал его временно вообще отключить.

Конечно-же, в прерывании вообще никаких функций не вызывается. Оба места - 2 разных автомата состояний в основном цикле.
Компилятор ImageCraft.
По памяти:
data 258. bytes (rel,con,ram)
bss 1731. bytes (rel,con,ram)
ИТОГО 1989байт, остатся 59 байт... для стека.
ram_end = 0x8ff
hwstk_size = 0x28



SP покажет только если стек "не уравновешен", поэтому не стал сразу его выводить...
Эта тема?
https://electronix.ru/forum/index.php?showt...%E5%F0%ED%EE%EC

С WatchDog проблема.... я писал ссылку на тему.
https://electronix.ru/forum/index.php?showtopic=140918
Не получается его задействовать, как надо - если в режиме прерывания, то работает, а если в режиме СБРОС - то проц просто завешивается. Это в тестовом проекте пробовал.

И самое забавное - что как "зависнет", точно так-же само и "отвисает".... хотя, может, не всегда...
Ещё момент - UART подключен через коммутатор, т.е. есть несколько (3 источника данных). Переключение асинхронное по отношению к данным.
Сейчас думаю попробовать при переключении коммутатора, чистить регистры приёмника. Хотя, раз прерывание по приёму продолжает работать, то, навряд-ли что-то изменится.

Значит на стек для параметров и локальных переменных остается 0x12 = 18 байт.
Явный перевес в сторону Hard Stack-a, который позволит сделать вложенный вызов 19-ти функций.
Его можно уменьшить.

Не совсем понял про стек.... поясните.
На счёт вложенности - есть ф-ция main, в ней вызываются по очереди другие ф-ции (максимальное число параметров - 3, целые) и прерывание.
8 регистров заносится в стек при вызове обработчика приёма, 9 регистров при вызове обработчика передачи. 5 регистров при вызове таймера.
Ну + точка возврата - 11 байт....

Некоторые компиляторы создают два отдельных стека "hard" и "soft". hwstk_size - это "hardware stack".
hard-stack - это стандартный аппаратный стек, адресуется указателем стека SP, "push" и "pop" - это его команды и предназначен он
исключительно для помещения в него адресов возврата при вызове функций и прерываний.
Для передаваемых параметров и локальных переменных создается soft-stack. Он адресуется парой регистров Y и сохранение/извлечение
из него происходит с помощью команд загрузки/сохранения через Y.
Как правило, soft-stack требует большего размера нежели hard-stack.

Понятно, что имеете в виду под soft-стеком. Некоторые компиляторы туда-же складывают локальные переменные.
Просмотрел листинг и увидел, что есть адресация временных переменных по y+62!!!
Изменение значения y Не стал отслеживать, но похоже, что +62 явно выйдет за пределы....
Полагал, что компилятор должен отслеживать использование памяти....
Поправил исходник так, чтобы избавиться от таких временных переменных. Буду смотреть результат...

Ну, пока что сутки отработало без зависаний...
Посмотрю ещё сутки, чтобы не сделать вывод преждевременно...

Зависать перестало.
Причина была в использовании памяти промежуточными результатами вычислений.
Заменил выражения вида:

выражениями вида:

И в ассемблерном листинге исчезли команды типа

И всё стало ограничиваться


Спасибо за подсказки.

ImageCraft - не самый лучший выбор. Хуже разве что CodeVision.
Не хотите увлекательных квестов в будущем - переходите на avr-gcc (бесплатно), либо на iar (если есть лишние деньги).

либо на ассемблер и абсолютно бесплатно