Что может привести к неожиданному сбросу микроконтроллера?

Одна особенно раздражающая разновидность ошибок в системе, управляемой микропроцессором, заключается в неожиданном сбросе микропроцессора. Важным инструментом для устранения проблем такого рода является список возможных причин. Что может привести к неожиданному сбросу микроконтроллера?

На чипах PIC и dsPIC я наблюдал следующие причины неожиданного сброса.

Оборудование:

• Сбросить штифт на низкий или плавающий Сначала проверьте очевидные вещи!
• ESD соединение в контакт сброса. Я видел, как это происходит, когда на одном столе включается совершенно не связанное оборудование. Убедитесь, что на выводе сброса достаточно емкости, возможно, до 1 мкФ.
• ESD-соединение с другими выводами процессора. В частности, зондовые датчики могут выступать в роли антенн, связывать шум с микросхемой и вызывать странные сбросы. Я слышал сообщения о неправильных кодах сброса.
• Плохой паяный шов / прерывистый мост. Может быть потеря или короткое замыкание на шине питания, либо на процессоре, либо где-то еще на плате.
• Усилитель рельса глюк / шум Может быть вызвано любым количеством внешних проблем, в том числе поврежденным регулятором или провалом в сети. Убедитесь, что силовые шины питания процессора стабильны. Может потребоваться больше заглушки где-нибудь, возможно, развязывание заглушки непосредственно на процессоре
• Некоторые микроконтроллеры имеют вывод Vcap, который не должен быть подключен к VDD и должен иметь собственный общий конденсатор. Неправильное подключение этого контакта может привести к непредсказуемым результатам.
• Если отрицательный аналоговый вход превысит определенный предел, произойдет сброс, который в RCON сообщает об отключении. То же самое можно сказать и о цифровых входах.
• Очень высокое значение dV / dt в близлежащем преобразователе питания может вызвать сброс напряжения питания. (См. Этот вопрос .) Я видел это в двух случаях, и в одном я смог отследить его до емкостной связи. IGBT коммутировал 100-200 ампер, и при отключении некоторые цепи обратной связи видели шум в несколько микросекунд, от 2 В до 8 В на процессоре 3,3 В. Увеличение крышки фильтра на этой направляющей обратной связи остановило сброс. Можно предположить, что добавление фильтра du / dt через транзистор могло бы иметь аналогичный эффект.

Програмное обеспечение:

• Сторожевой таймер. Удостоверьтесь, что сторожевой таймер очищается достаточно часто, особенно в ветвях вашего кода, выполнение которых может занять много времени, как пишет EEPROM. Проверьте это, отключив сторожевой таймер, чтобы убедиться, что проблема исчезла.
• Разделить на ноль. Если вы выполняете какую-либо операцию деления в своем коде, убедитесь, что делитель никогда не может быть равен нулю. Добавьте проверку границ перед делением. Не забывайте, что это также относится к операциям по модулю .
• Переполнение стека. Слишком много вызовов вложенных функций может привести к тому, что системе не хватит динамической памяти для стека, что может привести к сбоям в необычных точках выполнения кода.
• Стека стека. Если вы программируете на ассемблере, вы можете случайно выполнить больше ВОЗВРАТОВ, чем выполнили ВЫЗОВ.
• Несуществующая подпрограмма прерывания. Если прерывание разрешено, но подпрограмма прерывания не определена, процессор может сброситься.
• Несуществующая рутина ловушек. Похоже на процедуру прерывания, но достаточно отличается, я перечислю это отдельно. Я видел два отдельных проекта, использующих dsPIC 30F4013, которые сбрасывались случайным образом, и причина была отслежена в ловушке, которая была вызвана, но не определена. Конечно, теперь у вас есть вопрос, почему в первую очередь вызывается ловушка, которая может быть любым, включая ошибку кремния. Но определение всех обработчиков ловушек должно быть хорошим ранним шагом в диагностике необъяснимых перезагрузок.
• Ошибка указателя функции. Если указатель на функцию не указывает на правильное местоположение, разыменование указателя и вызов функции, на которую указывает указанная функция, может вызвать сброс. Одна забавная причина этого была, когда я инициализировал структуру, с последовательными значениями NULL (для указателя функции) и -1 (для целого). Запятая была опечатана, поэтому указатель на функцию фактически был инициализирован как NULL-1. Так что не думайте, что только потому, что это CONST, оно должно содержать действительное значение!
• Неверный / отрицательный индекс массива. Убедитесь, что вы выполняете проверку границ для всех индексов массива, как верхних, так и нижних границ, если это применимо.
• Создание массива данных в памяти программ, который больше, чем самый большой раздел памяти программ. Это может даже не вызвать ошибку компиляции.
• Преобразование адреса структуры в указатель на другой тип, разыменование этого указателя и использование разыменованного указателя в качестве значения LVALUE в операторе может вызвать сбой. Смотрите этот вопрос . Предположительно, это также относится к другим неопределенным моделям поведения.

В некоторых dsPIC регистр RCON хранит биты, указывающие причину сброса. Это может быть очень полезно при отладке.

Контакт RESET должен надлежащим образом управляться цепью сброса, отслеживая повышенное / пониженное напряжение и создавая достаточно длинный сигнал сброса. Имея это в виду, мой опыт с неконтролируемой перезагрузкой аппаратного обеспечения приходит тогда из:

• Перекрестные помехи от переключения линий на вывод / линию RESET (сделайте их короткими)
• Сдвиги / петли заземления, вызванные включением / выключением внешней сильноточной нагрузки
• Пик напряжения не фильтруется источником питания и слишком короток, чтобы активировать правильный сброс
• Переключение внешних нагрузок с помощью микроконтроллера, которое вызывает вышеуказанные проблемы (в основном на индуктивные нагрузки, такие как включение / выключение двигателя, реле или старая лампа (пусковой ток)
• Пик напряжения / тока на любом из выводов микроконтроллера (в худшем случае это осциллятор) может вызывать обратный ток и может переключать внутренний регистр (так же, как пики напряжения на линии питания). В целом, при взаимодействии с некой промышленной средой необходимо соблюдать осторожность (подробнее см .: http://www.ichaus.biz/wp1_mcu_interface ). Необходимо учитывать сдвиг уровня на входах / выходах, входную фильтрацию и выходы с мягким переключением. Чистота линий снабжения имеет первостепенное значение для аппаратной части. Затем RESET и выводы генератора, затем IO-линии. -mm

Еще одной возможностью, которую я не увидел в этом списке, является устройство, поддерживающее ICSP. Если на линиях, которые запускаются в режиме последовательного программирования схемы, используется недостаточное подтягивание, иногда можно войти в этот режим случайным образом. Это приводит к сбросу через короткий промежуток времени, когда на назначенные последовательные приемные линии не отправляется обновление программы. Я подозреваю, что внутренний сторожевой таймер принудительно сбрасывается, если ICSP запущен и никакие данные программирования не отправляются. Это ошибка, которую я сделал и потратил много времени на поиск 16F876.

Убедитесь, что вы используете в своей схеме логические микросхемы CMOS или TTL, чтобы они имели достаточные развязывающие конденсаторы через Vdd и землю (обычно 0,1 мкФ). Я использовал CD4021 в дизайне, и когда он использовался, очевидно, он вызывал некоторый всплеск, который вызывал перезапуск микропроцессора. Тогда цикл будет повторяться. По этой же причине рекомендуется запускать очевидную последовательность тестов (например, несколько раз мигать светодиодом) в начале кода, чтобы вы знали, что микропроцессор работает и выполняет код.

Это одна из тех редких вещей, которые могут появиться:

У меня был проект, в котором был задействован микроконтроллер, и он сам по себе периодически сбрасывался. Короче говоря, оказывается, что некоторые опции должны были быть включены или отключены, иначе может произойти сброс. Я узнал об этом только прочитав опечатки после того, как отказался от всего остального

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