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

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

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

Спасибо.

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

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

Код покажите.
Если прерывание постоянно куда-то уводит 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


Сообщение отредактировал Ioann_II - Mar 15 2017, 23:41

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

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

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