Может ли плотная петля уничтожить ячейки микроконтроллера?

Question

Хорошо известно, что флеш-память имеет ограниченную выдержку для записи, тем более что считывание может также иметь верхний предел such as mentioned in this Flash endurance test's Заключение (3-е место).

На микроконтроллере код обычно хранится во Flash и выполняется путем извлечения кодовых слов непосредственно из флеш-чейков.
(по крайней мере, это обычно так на 8-битных микрофонах, некоторые 32-битные микроны могут иметь небольшой буфер).

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

Это может генерировать 100 Кбайт или даже больше (чтение) доступов в секунду в среднем к одной ячейке вспышки (в зависимости от часов и конкретного кода).

Может ли такой код фактически уничтожить ячейки Flash под ним?

(Есть ли необходимость заботиться об этой конкретной проблеме при разработке кода для микроконтроллеров? Например, часть системы, предназначенная для работы в течение многих лет? Конечно, Flash может периодически проверяться CRC, но это не так предотвратите отказ системы, если это произойдет, только то, что сбой будет более вероятным в контролируемом режиме)

Answer 1

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

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

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

Answer 2

Я знаю двух методов, чтобы подойти к этому вопросу:

1) Один из методов является выделить константный 32-битное целое переменную в коде системы. Затем вычислить контрольную сумму CRC32 скомпилированного двоичного изображения и вставить контрольную сумму в зарезервированную переменную с помощью ELF-редактора. Модуль в системном программном обеспечении затем вычисляет CRC32 по области флэш-памяти, занимаемой приложением, и сравнивается с «сохраненным» значением. Если вы используете GCC, компоновщик может определить символ, чтобы сообщить вам, где сегмент останавливается. Этот метод может обнаруживать ошибки, но не может их исправить.

2) Еще один способ - использовать микроконтроллер, поддерживающий Flash ECC. TI продает Cortex-R4 MCU, которые поддерживают Flash ECC (серия Hercules).

Answer 3

Я сомневаюсь, что это практическая проблема. В приводимой вами статье смутно утверждается, что это может произойти, но без подтверждающих доказательств или количественной оценки эффекта. Существует смутное, неподдерживаемые и бескванторная ссылка во введении:

[...] вспышка деградирует с течением времени от стирания/записи (или даже просто чтение, хотя, что распад происходит медленнее) [...]

Затем снова в заключении:

• Мы не проверяли флэш-распада для чтения, но чтение также вызывает долгосрочный спад. Было бы интересно узнать, достаточно ли мы можем прочитать пятно, чтобы вызвать сбой.

Автор может иметь в виду считывания нарушения в NAND флэш, но микроконтроллеры не используют NAND флэш-памяти для хранения кода/исполнения, так как он не является произвольным доступом. Чтение нарушения не является постоянным эффектом, стирание и повторная запись затронутого блока восстанавливает выносливость. Контроллеры NAND поддерживают количество отсчетов для блоков и автоматически копируют и стирают блоки по мере необходимости. Они также используют ECC для обнаружения и исправления ошибок, а также для определения областей с «записью носителей».

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

Большинство систем RTOS тратят большую часть времени на обработку в режиме бездействия и работают круглосуточно 24/7 365 дней в году. Некоторые процессоры поддерживают команду wait-for-interrupt, которая останавливает CPU в холостом цикле, но далеко не все, и это не редкость не использовать такую ​​инструкцию. Процессоры с флэш-ускорителями или кэшами также могут препятствовать непрерывной быстрой выборке из одного места, но опять же это далеко не все микроконтроллеры.