Повреждение флэш-памяти AVR


11

Этот вопрос связан с самой депрограммированием AVR .

Информация о проекте: у
нас есть продукт с батарейным питанием, использующий ATMEGA644P. Приложение постоянно работает в спящем режиме и просыпается только раз в секунду (RTC) или при срабатывании одной из двух внешних линий прерывания.

Устройство оснащено довольно простым загрузчиком, который общается через UART (используя ИС интерфейса RS232). Он просто служит удобным способом обновления прошивки, так что не требуется аппаратный ISP-программист. (Загрузчик ожидает телеграмм с защитой контрольной суммы)

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

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

Это сравнение исходного содержимого флэш-памяти (слева) с поврежденным содержимым (справа):

Flash сравнение

Некоторые наблюдения:

  • Поврежденный блок всегда состоит как минимум из одной флэш-страницы (256 байт) и выровнен по странице. Другими словами: затрагиваются только целые страницы, а не отдельные байты.
  • Поврежденный контент большую часть времени читает 0xFF, но может также содержать некоторые другие значения или быть полностью «случайным».
  • Маленькая полоска на левой стороне изображения показывает все затронутые области. Для этого устройства это примерно одна десятая от общего содержимого флэш-памяти.
  • У нас было одно устройство, на котором была затронута только одна страница.

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

Возможно, контроллер случайно перезагружается из-за пониженного напряжения, и код загрузчика в это время работает совершенно непредсказуемо. Процитирую парня с другого форума относительно пониженного напряжения:

«Выполняются не только случайные инструкции из флэш-памяти, но и период случайных инструкций (нет гарантии, что код из флэш-памяти будет прочитан и интерпретирован правильно). Вместе с тем другие части mcu могут работать не так, как задумано, включая защиту механизмы «.

Вопрос (ы):
Считаете ли вы, что «случайное поведение при пониженном напряжении и выполнении некоторых инструкций, изменяющих данные на флэш-страницах» - объяснение является обоснованным? Если это так, то почему мы не видим подобные ошибки постоянно как причину некоторых программных проблем (переполнение стека, неверные указатели).

Есть ли у вас какие-либо идеи, что может привести к коррупции такого рода? Может ли это быть вызвано EMI / ESD?


Во втором блоке в вашем примере были ли биты от 1-> 0 или все они все 0-> 1 переходы? У меня есть скрипт, который вычисляет это, но я не собираюсь вводить все цифры из вашего скриншота.
markrages

@markrages: от просмотра только 0-> 1. В одном ответе также указывалось, что это выглядит как частичное стирание, когда не все биты были сброшены на 1. Спасибо за наблюдение.
Rev 1.0

Ответы:


11

Вы должны заметить, что вспышка не пишется, она стирается. Стертая вспышка полна 0xFF. Ваши первые 256 байтов полностью стерты, ваша третья 256-байтовая область частично стерта (у вас есть только от 0 до 1 бит-кадров от правильных данных до поврежденных).

Согласно данным таблицы , эта флэш-память стирается страницей (обычно я работаю с блоками стирания, большими, чем страницы). Как видно на странице 282, выполнить удаление страницы с помощью SPM довольно просто.

Вы можете быть заинтересованы в разделе 23.8.1 (Предотвращение повреждения Flash):

Повреждение программы Flash может быть вызвано двумя ситуациями, когда напряжение слишком низкое. Во-первых, для правильной работы обычной последовательности записи во Flash требуется минимальное напряжение. Во-вторых, сам ЦП может выполнять команды неправильно, если напряжение питания для выполнения команд слишком низкое. Повреждения флэш-памяти можно легко избежать, следуя этим рекомендациям по проектированию (достаточно одного):

  1. Если в системе нет необходимости обновлять загрузчик, запрограммируйте биты блокировки загрузчика, чтобы предотвратить любые обновления программного обеспечения загрузчика.
  2. Держите AVR RESET активным (низким) в периоды недостаточного напряжения питания.
    Это можно сделать, включив внутренний детектор отключения (BOD), если рабочее напряжение соответствует уровню обнаружения. Если нет, можно использовать внешнюю схему защиты от сброса низкого VCC. Если сброс происходит во время операции записи, операция записи будет завершена при условии достаточного напряжения источника питания.
  3. Держите ядро ​​AVR в режиме ожидания при отключении питания во время периодов низкого VCC. Это предотвратит попытку процессора декодировать и выполнить инструкции, эффективно защищая регистр SPMCSR и, следовательно, Flash от непреднамеренной записи.

Ваше наблюдение о частичном удалении на третьей странице кажется правдоподобным. Относительно текста Atmel: Мы все согласны с тем, что BOD представляется обязательным. Но я все еще не уверен в ТОЧНОЙ причине коррупции. Разве не маловероятно, что контроллер просто выполняет (из-за низкого напряжения) эту конкретную инструкцию, чтобы стереть флэш-страницу? Я имею в виду, что это могло бы произойти даже во время выполнения кода загрузчика, поскольку флэш-память доступна только для записи. И это требует определенной последовательности.
Ред. 1.0

3
Невозможно объяснить точный источник повреждения: когда ваш Vcc падает, он становится слишком низким, чтобы полностью насытить один транзистор другим. MCU - это очень большое логическое уравнение. Если ваши транзисторы перестают вести себя как логические переключатели, вы меняете это уравнение. Поскольку неисправность первого транзистора зависит от легирования пластин ASIC и внешних электромагнитных возмущений, вы не можете предсказать, что произойдет. Чтобы решить эту проблему, при разработке ASIC вы можете добавить аналоговую часть, которая отключает цифровую часть перед неправильным поведением. Но это увеличивает всю стоимость ASIC.
Джейсен

Приводя в заблуждение, что в примечании к приложению AVR180 указано, что защита от внешнего отключения : «Обратите внимание, что на содержимое внутренней флэш-памяти программ AVR® никогда не влияет недостаточное напряжение питания». Далее: «Поскольку ЦП AVR не способен записывать в свою собственную память программ, содержимое внутренней памяти программ Flash никогда не зависит от сбоя питания». - IMO Atmel просто игнорирует, что есть что-то вроде загрузчиков, которые ДОЛЖНЫ менять флэш-память.
Rev 1.0

@ Rev1.0 Ну да, это маловероятно ... вот почему вы видите его только на одном устройстве каждые несколько месяцев, а не на всех устройствах все время.
user253751

«Я имею в виду, что это могло бы произойти даже во время выполнения кода загрузчика, поскольку флэш-память доступна только для записи». - Это верно только в том случае, если биты блокировки загрузки ( BLB01и друзья) установлены правильно! Они? «Смущает ... примечание к приложению ...» - Примечания к приложению общеизвестно ненадежны. Используйте их только для вдохновения; для гарантий положитесь на таблицы данных (которые также не безошибочны, но эй).
Марсель

4

Это хорошо известная проблема, которая затрагивает многие микроконтроллеры (не только Atmel). Аппаратные средства управления флэш-памятью повреждают или стирают часть памяти в условиях низкого напряжения. Простое решение состоит в том, чтобы включить защиту от отключения.

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


3
Есть ли у вас какие-либо убедительные ссылки на то, КАК и ПОЧЕМУ «аппаратное обеспечение управления памятью повреждает или стирает часть памяти в условиях низкого напряжения»? На форуме много дискуссий о флеш-коррупции, но она почти никогда не сводится к чему-то твердому, поэтому я и спросил здесь.
Rev1.0

Это проблема пониженного напряжения в микросхеме или это связано с неправильным / случайным выполнением программы в секции загрузчика, которую AFAIK может изменять только FLASH. Если второе - проблема, отключение выполнения загрузчика через FUSE должно решить проблему.
TMa

Я помню, как читал об этом, по крайней мере, в одной MEGA micro.
пользователь

3

Пониженное напряжение является очень вероятной причиной. Например, у меня когда-то был проект, в котором уровень отключения 1,8 В часто вызывал повреждение, и эти повреждения никогда не могли быть воспроизведены с уровнем отключения 3,5 В.

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


1
Спасибо за ответ. Мы закончили с использованием внешнего детектора с ультранизким энергопотреблением и с тех пор у нас не было проблем с повреждением.
Rev 1.0

0

EMC станет вашим главным врагом, если вы не будете следовать основным правилам проектирования печатных плат. Вот наиболее важные из моего собственного опыта: - блокировка конденсаторов на любой микросхеме, независимо от того, что производители сообщают вам в своих таблицах данных об адских схемах, поместите по крайней мере один от 100 пФ до 1 нФ на линии электропередач каждой микросхемы - проводящие заземления на слой каждой печатной платы как можно больше. Эти области должны контактировать через все слои через переходы настолько часто, насколько это возможно, сетка в 50 миль является хорошим значением. Подключите эти области к заземлению. - Никогда не оставляйте неподключенную (плавающую, без сигнала) медь на вашей печатной плате. Он действует как антенна и изобретательно наносит электромагнитное излучение на устройства - делает следы, несущие тактовые сигналы, как можно короче

Более подробную информацию можно найти в запросах поисковых систем, таких как "Руководство по разработке emc proof pcb".

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