Перейти к содержанию
    

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

 

Столкнулся со странным зависанием упомянутой микросхемы.

Основной цикл перестаёт выполняться, но вот прерывание продолжает работать.

Не программное, т.к. каждый раз останаливается в разном месте.

Конденсаторы по питанию, на кварце стоят.

 

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

 

Спасибо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну, почему же "не программное"?

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Обработчики прерываний на месте и в порядке.

Останавливается именно обработка главного цикла. При чём в разных местах.

Завтра буду осциллографом питание смотреть на предмет иголок....

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Код покажите.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Останавливается именно обработка главного цикла. При чём в разных местах.

"Останавливается" - Это просто пи-дец!!!

До тех пор пока Вы будете предполагать что процессор может как-то "ЗАВИСНУТЬ" вы никогда не найдёте ошибку в Вашем коде.

Попробуйте исходить из того что "зависнуть" процессор просто не может НИ-КО-ГДА .

Примите это как аксиому и ищите косяки в своём коде.

А если пишете на СИ - будьте готовы к тому, что придётся искать не только свои но и чужие КОСЯКИ! :biggrin:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А если пишете на СИ - будьте готовы к тому, что придётся искать не только свои но и чужие КОСЯКИ! :biggrin:

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Ну для AVR можно и на СИ каждую строку самовыстрадать.

Да и вполне разумно: код небольшой, в дальнейшем дешевле выйдет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Снова, спустя 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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Пока она применялась в одном только месте - всё работало... как ещё в одно поставил - начались "чудеса".

Избавился от sprintf - и "чудеса" пропали...

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Это совершенно бесполезная информация. Зависание произошло после вывода на LCD, и если оно стало результатом порчи стека Вы этого не увидите.

Для проверки целостности лучше заливать стек паттерном и проверять его содержимое.

Как залить - тема тут была ранее.

Если используете WatchDog, посмотрите как часто Вы его передергиваете. Я бы порекомендовал его временно вообще отключить.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...