Пошкодження флеш-пам’яті AVR


11

Це питання пов'язане з самою депрограмуванням AVR .

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

Пристрій оснащений досить простим завантажувачем, який спілкується через UART (використовуючи інтерфейс RS232 IC). Він просто служить зручним методом для оновлення мікропрограмного забезпечення, щоб не вимагати програмного забезпечення апаратного провайдера. (Завантажувач очікує захищених контрольною сумою телеграм)

Пристрої були розроблені з внутрішньо-коричневим відключенням, оскільки він вдвічі збільшує енергоспоживання, а довгий час роботи акумулятора є обов'язковим (я думаю, що слід було використовувати зовнішнє виявлення коричневого кольору - переробляється робота).

Проблема:
кожні кілька місяців пристрій просто припиняє роботу, на цих пристроях не було оновлених програмних засобів. Однак після подальшого огляду вміст спалаху цих пристроїв здається пошкодженим. Більше того, батареї деяких із цих пристроїв були все-таки хорошими, але я не хочу виключати якусь ситуацію з перенапругою.

Це порівняння вихідного вмісту спалаху (зліва) зі зіпсованим вмістом (праворуч):

Flash порівняння

Деякі зауваження:

  • Пошкоджений блок завжди складається щонайменше з однієї флеш-сторінки (256 байт) і вирівнюється на сторінці. Іншими словами: Зачіпаються лише цілі сторінки, а не один байт.
  • Пошкоджений вміст читає 0xFF більшу частину часу, але може містити деякі інші значення або бути повністю "випадковим".
  • Невелика смужка на лівій стороні зображення показує всі уражені ділянки. Для цього пристрою його приблизно одна десята частина загального вмісту спалаху.
  • У нас був один пристрій, на якому впливала лише одна сторінка.

Цілком правдоподібно, що умова перенапруги під час запису флеш-пам'яті може пошкодити вміст флеш-пам'яті. Однак це означає, що деякі інструкції, чутливі до спалаху, повинні бути виконані.

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

"Виконуються не лише випадкові вказівки із спалаху, але й період випадкових інструкцій (немає гарантії, що код з флеш буде прочитаний та інтерпретований правильно). Поряд з цим інші частини mcu можуть не вести себе як розроблено, включаючи захист механізми ».

Питання:
Чи вважаєте ви, що "випадкова поведінка під час перенапруги та виконання деяких інструкцій щодо зміни даних на флеш-сторінках" - пояснення звучить? Якщо це так, то чому б ми не бачили цей тип помилок весь час лише як причину деяких програмних проблем (переповнення стека, недійсні покажчики).

Чи є у вас інші ідеї, що може спричинити такий вид корупції? Чи може це бути викликано EMI / ESD?


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

@markrages: якщо дивитися на нього, лише 0-> 1. Одна відповідь також вказувала, що це виглядає як часткове стирання, де не всі біти були перевернуті на 1. Дякую за спостереження.
Rev1.0

Відповіді:


11

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

Відповідно до даних , цей спалах стирається на сторінці (я зазвичай працюю з блоками стирання, більшими за сторінки). Як видно на сторінці 282, виконувати стирання сторінки за допомогою SPM досить просто.

Вас може зацікавити розділ 23.8.1 (Запобігання пошкодженню спалаху):

Пошкодження програми Flash може бути спричинене двома ситуаціями, коли напруга занадто низька. По-перше, звичайна послідовність запису на спалах вимагає мінімальної напруги для правильної роботи. По-друге, сам процесор може виконувати інструкції неправильно, якщо напруга живлення для виконання інструкцій занадто низька. Спалах корупції легко уникнути, дотримуючись цих рекомендацій щодо дизайну (одного достатньо):

  1. Якщо в системі немає необхідності оновлення завантажувача завантажувача, запрограмуйте біти Locker Lock Lock, щоб запобігти будь-яким оновленням програмного забезпечення завантажувача.
  2. Тримайте AVR RESET активним (низьким) у періоди недостатньої напруги живлення.
    Це можна зробити, включивши внутрішній детектор коричневого відключення (БПК), якщо робочий вольт-вік відповідає рівню виявлення. Якщо ні, можна використовувати зовнішній ланцюг захисту від скидання VCC. Якщо скидання відбувається під час операції запису, операція запису буде завершена за умови достатньої напруги живлення.
  3. Тримайте ядро ​​AVR в режимі сну при відключенні живлення в періоди низького рівня VCC. Це не дозволить ЦП намагатися розшифрувати та виконати інструкції, ефективно захищаючи Реєстр SPMCSR і, таким чином, Flash від ненавмисних записів.

Ваші спостереження щодо часткового стирання на третій сторінці здаються правдоподібними. Щодо тексту Атмеля: Ми всі згодні, що БПК здається обов'язковим. Але я все ще не впевнений у точній причині корупції. Хіба це малоймовірно, що контролер просто виконує (через низьку напругу) цю специфічну інструкцію для видалення флеш-сторінки? Я маю на увазі, це могло б статися навіть під час виконання коду завантажувача, оскільки спалах записується лише звідти. І для цього потрібна певна послідовність.
Rev1.0

3
Неможливо пояснити точне джерело корупції: коли ваш Vcc падає, він стає занадто низьким, щоб повністю наситити один транзистор іншим. MCU - це в основному дуже велике логічне рівняння. Якщо ваші транзистори перестають вести себе як логічні перемикачі, ви зміните це рівняння. Оскільки перший транзистор, який не поводиться, залежить від допінгу ASIC Wafer та зовнішніх електромагнітних збурень, ви не можете передбачити, що відбудеться. Щоб вирішити цю проблему, розробляючи ASIC, ви можете додати аналогову частину, яка вимикає цифрову частину перед недоброзичливим поведінкою. Але це збільшує всю вартість ASIC.
Ясен

Заплутано те, що в примітці додатка AVR180 Зовнішній захист від коричневого кольору зазначено: "Зверніть увагу, що на вміст внутрішньої пам'яті програми AVR® ніколи не впливає недостатня напруга живлення". Далі: "Оскільки процесор AVR не здатний записувати у власну програмну пам'ять, на вміст внутрішньої пам'яті програми Flash ніколи не впливає ситуація з відключенням живлення." - IMO Atmel просто ігнорує, що є щось на зразок завантажувачів, які МАЮТЬ змінити флеш-пам'ять.
Rev1.0

@ Rev1.0 Ну так, це малоймовірно ... саме тому ви бачите його лише на одному пристрої кожні кілька місяців, а не на всіх пристроях постійно.
користувач253751

"Я маю на увазі, це могло б трапитися навіть під час виконання коду завантажувача, оскільки спалах записується лише звідти." - Це справедливо лише в тому випадку, якщо біти блокування завантаження ( BLB01та друзі) встановлені належним чином! Чи вони? "Плутати ... примітка із додатком ..." - Примітки до програми, як відомо, ненадійні. Використовуйте їх лише для натхнення; для гарантій покладайтеся на дані (які також не є непогрішними, але є).
marcelm

4

Це добре відома проблема, яка стосується багатьох мікроконтролерів (не лише Atmel). Обладнання управління флеш-пам’яттю пошкоджує або стирає частину пам'яті в умовах низької напруги. Просте виправлення полягає в тому, щоб забезпечити захист від коричневого кольору.

Завжди слід завжди включати захист від коричневого кольору на мікроконтролерах.


3
Чи є у вас чіткі посилання про те, як і ЧОМУ "апаратне забезпечення управління пам'яттю пошкоджує або стирає частину пам'яті в умовах низької напруги"? Існує безліч дискусій на форумі щодо флеш-корупції, але вона майже ніколи не зводиться до чогось солідного, саме тому я тут запитав.
Rev1.0

Це проблема неполадки в мікросхемі чи вона пов'язана з неправильним / випадковим виконанням програми в розділі завантажувача, який AFAIK може змінювати FLASH. Якщо другий - проблема відключення виконання завантажувача через FUSE, слід вирішити проблему.
ТМа

Я пам’ятаю, як читав про це в Errata принаймні одного мікрофону MEGA.
користувач

3

Неповна напруга є дуже ймовірною причиною. Наприклад, у мене колись був проект, коли рівень коричневого відключення в 1,8 В часто спричиняв корупцію, і ці пошкодження ніколи не могли бути відтворені з рівнем коричневого виходу 3,5 В.

Зауважте, що чим швидше працює процесор, тим він чутливіший до проблем із напругою. Якщо зниження частоти процесора - це доступний варіант для вас, можливо, варто спробувати.


1
Дякую за відповідь Ми в кінцевому підсумку використовували зовнішній детектор коричневого випромінювання з низькою потужністю і з тих пір не мали проблем із корупцією.
Rev1.0

0

EMC стане вашим найбільшим ворогом, якщо ви не будете дотримуватися основних правил дизайну друкованих плат. Ось найважливіші з мого власного досвіду: - блокування конденсаторів на будь-якому ІС, незалежно від того, що виробники розповідають у своїх таблицях про інфернальні схеми, покладіть принаймні один між 100pF - 1nF на лінії електропередач кожного ІС - проведення наземних ділянок на кожен шар друкованої плати якомога більше. Ці ділянки контактуватимуть через усі шари через віаси настільки часто, наскільки це можливо, сітка частотою 50 мільйонів є хорошою цінністю. Підключіть ці ділянки до сигналу заземлення. - Ніколи не залишайте з’єднану (плаваючу, до сигналу) мідь у друкованій платі. Він діє як антена і девініфективно наносить електромагнітне випромінювання на пристрої - зробити сліди, що несуть сигнали годинника, як можна коротші

Знайдіть більше деталей за запитами пошукових систем, таких як "посібник із електронного друку для друку друкованих плат"

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.