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


26

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


1
Некоторые ответы здесь могут быть полезны: electronics.stackexchange.com/questions/30430/… Какой микроконтроллер вы используете?
Джон Л

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

2
это домашний вопрос?
old_timer

1
@dwelch Возможно, для кого-то, но не для меня и моих учеников.
Стивен Коллингс

1
@Vorac должен прочитать, что Atmel не может поддерживать надежность URL.
Каз

Ответы:


51

На чипах 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 хранит биты, указывающие причину сброса. Это может быть очень полезно при отладке.


1
вывод @reset: плавающий вывод сброса известен как случайный сброс. Всегда подключайте его к Vcc через резистор.
Джиппи

4
Это невероятно исчерпывающий список. Из моего опыта работы с AVR я считаю, что большинство, если не все, одинаковых ситуаций приведут к неожиданным результатам или сбросам.
HL-SDK

4
Позвольте мне добавить еще один для программирования на языке ассемблера - непревзойденный регистр PUSH и POP из стека.
Майкл Карас

2
Еще пара: под железом, сброс настроек. Под программным обеспечением, инструкция по сбросу программного обеспечения. Оба из них доступны на нескольких микроконтроллерах.
tcrosley

2
Еще один в списке: мобильные телефоны, расположенные рядом с кабелем, могут вызывать удивительно значительное напряжение на слабо управляемых линиях. Если у вас есть линия сброса, проходящая через кабель (например, одна плата может принудительно выполнить сброс другой), мобильный телефон рядом с кабелем может инициировать сброс, если, например, он принимает вызов.
суперкат

7

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

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

1
Земные сдвиги просто укусили меня. В моем случае у меня была определенная часть моей общей сети, несущая ~ 100 ампер. Микроконтроллер был привязан к одной стороне этой толстой трассы, но некоторые схемы, которые вел микроконтроллер, были привязаны к другому концу трассы. Трасса составляла всего 3 мОм, но при 100 амперах этого было достаточно, чтобы получить разницу в 300 мВ между микро- и периферийными устройствами, которыми он управлял. Перераспределил периферийные устройства, чтобы они были общими для того же конца трассировки, что и контроллер, и теперь все в порядке. Там нет такого понятия, как узел на этих токах.
Стивен Коллингс

4

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


3

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


2

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

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

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


Я даже не осознавал, что этот вопрос старый и ответ уже был предоставлен. К сожалению.
efox29
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.