Тест EEPROM памяти AVR микроконтроллера. Эксперимент

22/08/2013 - 18:34 Павел Бобков

Введение

   Внутренняя программа микроконтроллера AVR может читать и записывать любой байт EEPROM памяти. Однако при программировании EEPROM`a внешним программатором чтение и запись осуществляется постранично. В зависимости от типа микроконтроллера страницы EEPROM памяти имеют разный размер. Например, у микроконтроллера atmega16 размер страницы EEPROM памяти равен 4-ем байтам. 
   Существует мнение, что заявленный производителем ресурс EEPROM памяти AVR микроконтроллеров, равный 100000 циклов запись/чтение, относится не к единичной ячейке памяти, а к целой странице. То есть если мы в один байт EEPROM`а atmega16 запишем 100000 раз, остальные три ячейки страницы памяти потеряют свой ресурс, будучи вроде ни разу не тронутыми. 
   Мне стало интересно узнать, соответствует ли это действительности, и я провел небольшой тест EEPROM памяти atmega16. Понятно, что этот тест не является каким-то глубоким научным исследованием, но это все же лучше, чем ничего. 

Содержание теста

   Суть теста была предельно проста. В заданный байт EEPROM`a записывалось произвольное число, затем из этой же ячейки производилось чтение. Далее программа сравнивала записанное и считанное значение, и по результату сравнения увеличивался или счетчик удачных записей, или счетчик ошибок. Произвольное число генерировалось с помощью встроенной Си функции, а запись-чтение EEPROM`a производилось самописными функциями (чтобы можно было обращаться к EEPROM по конкретным адресам). 
   Каждые 10000 удачных записей в терминал выводилось сообщение с адресом тестируемой ячейки, числом произведенных записей и последним записанным числом. Таким образом, я контролировал, что микроконтроллер тестирует память, и каждый раз записывает разные числа. Также в терминал выводилось сообщение при появлении ошибок, чтобы отследить момент первого сбоя и посмотреть, как они накапливаются. 
   Ячейки тестировались в порядке возрастания адреса. Сначала "убивалась" 0-я ячейка, затем 1, 2 и так далее. То есть когда доходила очередь до последнего байта страницы (3 и 7 байты), предыдущие три были уже испорчены. 

Результаты теста EEPROM

   Всего я проверил 8 байтов EEPROM памяти atmega16, то есть две страницы. Да, это не так много, но вопреки моим ожиданиям ячейки оказались очень стойкими, и на тест одного байта уходило полдня. Полученные данные я свел в два графика. 
   Первый график отображает число циклов запись/чтение до появления первой ошибки. Из графика видно, что число циклов перезаписи для каждой ячейки составило не меньше 3 миллионов. Довольно большое число, но вряд ли ему стоит удивляться. Во-первых, заявленный ресурс EEPROM`a (100 тысяч), естественно, берется с большим запасом. Во-вторых, он указывается для всего рабочего температурного диапазона микроконтроллера, а я проводил тест только для комнатной температуры.
   Как видите, ресурс одной ячейки никак не зависит от ресурса другой. Если бы от одной испорченной ячейки портилась вся страница, соседние ячейки EEPROM`a в лучшем случае не показали бы такой же результат, а в худшем начинали сбоить практически сразу. Этого не было. Например, 2-ой байт вообще побил все рекорды, выдержав 6 миллионов записей, а ведь он тестировался третьим по счету. Делайте выводы. 

тест ресурса eeprom памяти

   
   Второй график, составленный по результатам теста, отображает характер «деградации» ячейки памяти. Дело в том, что даже после появления сбоев, EEPROM памятью еще можно пользоваться. Некоторое время ошибки возникают достаточно редко, и только после превышения определенного порога, ячейка начинает сбоить практически постоянно. Это значит, что программные способы коррекции ошибок, реально могут продлить ресурс EEPROM памяти и их нужно применять.

Выводы

   Заявленный фирмой Atmel ресурс EEPROM памяти микроконтроллеров AVR, равный 100 тысячам циклов запись/чтение, относится к ресурсу одного байта памяти, а не к целой странице.

Комментарии   

# Peter 23.08.2013 05:14
Кода нет, но по описанию вижу, что это, извините, не тот тест.
Тест - хотя бы вот как (типа псевдокод):
Оптимизация=none
long count;
EE(1) = 0; // Тестовые ячейки 1,2,3.
EE(2) = 0;
EE(3) = 0;
// Заведомо убить ячейку 0.
for(count= 0L;count < 10000000L;count ++){
// Писать в одну ячейку.В остальных - 0.
EE(0)= 0;
}
// Проверять другие ячейки страницы - пострадали ли они от записей в ячейку 0.
do{
EE(1)=0xaa;if( EE(1)!= 0xaa) break;
EE(1)=0x55;if( EE(1)!= 0x55) break;

EE(2)=0xaa;if( EE(2)!= 0xaa) break;
EE(2)=0x55;if( EE(2)!= 0x55) break;

EE(3)=0xaa;if( EE(3)!= 0xaa) break;
EE(3)=0x55;if( EE(3)!= 0x55) break;

НЕ ПОСТРАДАЛИ!
while(1) {;}

}while(0);

ПОСТРАДАЛИ!
while(1) {;}
Ответить | Ответить с цитатой | Цитировать
# Pashgan 23.08.2013 05:56
Ячейки тестировались в порядке возрастания адреса. Сначала "убивалась" 0-я ячейка, затем 1, 2 и так далее. То есть когда доходила очередь до последнего байта страницы (3 и 7 байты), предыдущие три были уже испорчены.Кажды й байт показал результат в 3 млн. записей. По-моему все очевидно.
Ответить | Ответить с цитатой | Цитировать
# Peter 23.08.2013 09:27
Давайте по шагам. Насколько я понимаю что нам надо сделать: нам надо понять, влияет ли запись в ячейку 0 на ресурс ячеек 1,2,3?
Так?
То есть хотим понять, пишется в ЕПРОМ за один раз вся 4-байтовая страница или пишется только один выбранный байт. Так?

Мы знаем, что ресурс ячейки "сжигается", когда в нее пишем b00000000.

То есть, при страничной записи, если во всех ячейках данной страницы находятся нули, то запись даже в одну из ячеек вызывает процессы СтираниеСтраниц ы и ЗаписьСтраницы, то есть все 4 байта стираются и ОПЯТЬ перезаписываютс я нулями.

То есть гробится ресурс всех 4-х байт страницы.

Ваш тест как это покажет? Ну убивается ячейка 0, а в ячейке 1 лежит FF и ее ресурс не уменьшается. И не поймешь, страница пишется или нет. А Вы перед тем как писать в яч.0 - обнулите все другие ячейки страницы, - пусть они тоже перезаписываютс я (если конечно там действительно страничная запись).
Ответить | Ответить с цитатой | Цитировать
# Pashgan 23.08.2013 11:01
Хорошо, проведу тест, обнулив ячейки.
Ответить | Ответить с цитатой | Цитировать
# Pashgan 25.08.2013 10:23
Проверил три байта (8, 9, 10) третьей страницы EEPROM`a предварительно обнулив ячейки. Пока что все то же самое, что и с предыдущими ячейками памяти. Никаких изменений.
Ответить | Ответить с цитатой | Цитировать
# Pashgan 27.08.2013 06:48
По результатам теста еще одной страницы, могу сказать, что разницы никакой. Что с обнулением ячеек, что без - ресурс отдельной ячейки никак не влияет на ресурс других.
Ответить | Ответить с цитатой | Цитировать
# vovka_kuk 31.08.2013 09:10
Классный тест. А если только считывать с еепром (запись и стирание не проводить), то на сколько раз хватит?
Ответить | Ответить с цитатой | Цитировать
# v3launch 04.09.2013 11:32
сколько угодно, чтение не влияет на ячейку
Ответить | Ответить с цитатой | Цитировать
# dima 25.12.2013 11:34
очень интересно. Получается что ресурс eeprom намного больше чем заявляет производитель. Интересно относится ли это и к флеш памяти программ? Производитель заявляет о 10000 циклов записей. Возможно это число так же будет больше.
Ответить | Ответить с цитатой | Цитировать
# Pashgan 25.12.2013 15:00
По тесту одного микроконтроллер а и в одних климатических условиях сделать однозначный вывод нельзя. Думаю ресурс берется с большим запасом. С флэш памятью скорее всего так же.
Ответить | Ответить с цитатой | Цитировать
# dima 26.12.2013 06:42
100000 заявленных циклов записи против 6-ти миллионов, запас однако в 600 раз. Неслабо ведь. Если предположим запас памяти программ взять в два раза то уже будет 20000 тыс. А ведь можно же сделать такой же тест и на память программ? Использовать команду spm на запись данных во флеш память. Паша, может организуешь :lol: ? Очень интересно было бы узнать результаты теста.
Ответить | Ответить с цитатой | Цитировать
# Pashgan 27.12.2013 05:15
А смысл тестировать флэш память? Она не используется для хранения меняющихся данных, в отличии от EEPROM`a.
Ответить | Ответить с цитатой | Цитировать
# dima 27.12.2013 05:44
В ходе исполнения программы можно перезаписывать отдельные участки флеш памяти. Так называемое самопрограммиро вание. То есть мк может менять свой исполняемый код.
Ответить | Ответить с цитатой | Цитировать
# Pashgan 27.12.2013 05:46
Я знаю, но эта функция используется только для загрузки прошивки бутлоадером. С переменными так обычно не работают.
Ответить | Ответить с цитатой | Цитировать
# dima 27.12.2013 08:34
Ну да с переменными так не работают, это понятно. Я ж говорю это для теста. Предположим есть некое устройство на AVR, которое работает в реальных промышленных условиях. ну и скажем есть реальный оператор который должен по некоторым причинам менять прошивку 10 раз в день. До 10000 перезаписей хватит на 2,7 лет. Так вот просто интересно насколько больше ресурс флеш памяти чем указано производителем.
Ответить | Ответить с цитатой | Цитировать
# dima 27.12.2013 05:46
В смысле программатором 10000 тыс раз можно только записать программу, а потом вроде как памяти кирдык. Так вот хотелось бы узнать каков на самом деле ресурс 10000 или больше.
Ответить | Ответить с цитатой | Цитировать
# Pashgan 27.12.2013 06:17
На моей памяти я не "убил" ни одного контроллера большим количеством перезаписи памяти. Так что это не причина для беспокойства.
Ответить | Ответить с цитатой | Цитировать
# Виктор 27.03.2014 11:14
статья-бомба. в пух и прах все мифы.
Ответить | Ответить с цитатой | Цитировать
# Yanichar 23.10.2016 19:20
тест совершенно некорректен, он совершенно не учитывает время хранения данных после записи, а ведь это ключевой параметр, наравне с температурой. В даташите всегда пишут X лет хранения после Y перезаписей при температуре Z, а у Вас что? Несколько (милли)секунд после 6млн. перезаписей. При износе изолятора ячейки растет ток утечки, и на сколько-нибудь длительное хранение рассчитывать глупо.
Ответить | Ответить с цитатой | Цитировать
# Heorenmaru 05.11.2016 21:24
Из этого теста ясно, что защиты у памяти нет.
Ответить | Ответить с цитатой | Цитировать

Добавить комментарий

Защитный код
Обновить