Первый раз на 8515 /если честно - не помню, чтоя там делал :о((/, но тогда просто пропустил - поскольку использовал для хранения отладочной информации по системе.
Второй раз на меге 8535 - получал обнуление по всем адрессам /хранил разгонную сетку частот для гиромотора, опять же на период обкатки системы/
Третий - на 32 меге. Первые четыре байта использую для хранения резонансных частот пьезодвигателя, пятый - для хранения адреса в системе (всего 12 модулей). На одной меге вместо записаного адреса 0х04, считываю то 0х04, то 0х05 то 0х0D. В программе для меги использовал функции работы с EEPROM от ИАР, во время работы программа сама ничего не пишет, только считывает по внешней команде. Ошибка в коде маловероятна, так как оставшиеся 11 модулей работают без нареканий.

Ответа от саппорта пока не получил.

Кто-то сталкивался с подобным? И как с этим бороться?

По нолевому адресу ни чего хранить нельзя. Иар с какой то версии сам обходит. при не корретной разводки, не соблюдении мер по устойчивости и т.д. программа может стартовать с любого адреса.
Сбой в работе мк врядли запортит данные (при чтении), а вот в чем вопрос - Иар при использовании только чтения не подставляет ли универсальную функции, которая и писать может? Если да, то сбой + указатель куданибудь и если на код записи, то /-/ данные.

Зашить в FUSE биты BODEN и BODLEV. При пониженом напряжении питания мк может выполнить любую команду. Проверить разводку платы на возможность кратковременых выбросов напряжения питания мк более 7V. (протекание больших силовых токов по общему мк)

У нас такой же сбой происходил давно, когда не ставили внешний супервизор по питанию.Сейчас при питании +5В ставим супервизор на +4,2В.

Нет, для чтения и записи используются разные функции.

Volodymyr, мне в своё время приходилось дорабатывать функции чтения\записи EEPROM, т. к. я их использовал в разных процессах (речь идёт об ОСРВ).
Посмотрите, не используете ли Вы их в прерываниях. В этом случае возможны сбои.

Непонятно Очень прошу пояснить

Тоесть если я использую хапись в EEPROM по прирыванию таимера (например) возможны сбои ???

Вот пример первой попавшейся функции из файла eeprom.s90, поставляемого с продуктом в папке avr\src\lib:
Предположим, что это выполняется в фоновой программе.
Если между OUT и SBI вклинится прерывание, изменяющее содержимое EEARL, то прочитано будет не то, что надо (не из того места).
Аналогично с записью.

Я поступил следующим образом:
... долго писАть, лучше приложу файл.
Подкорректировано всё, кроме той части, что касается AT86RF401.

Спасибо Все ясно

Сам имел проблемму с EEPROM очень давно (на АТ90 2313) Там было очень паршивое питание в схеме + я незнал о проблемме с нулевым адресом.

Счас хочу вынести на обсуждение одну идею.

Есть проект в котором нада хранить данные энергонезависимо + обновлять эти данные больше 100000 раз.

В датащитах пишут что гарантировано 100000 перезаписей - больше - негарантирують

Хотел создать в ЕЕПРОМЕ чтото вроже таблицы адресов сбоиных ячеек. Если после записи верификация не прошла то адрес заноситься в таблицу и прога больше непишет по ниму.

Таким образом пока все ЕЕПРОМ несдохнит девайс будет хранить данные нормально

Очень прошу мнений и критики

СПАСИБО
De}{teR

Хорошая идея DeXteR.

Идея-то хорошая, но не совсем прозрачная... где ты будешь хранить информацию о сбойных ячейках? а если и эти ячейки будут сбоить? много неочевидного =) у меня идея проще: писать во все ячейки по очереди, например 1 байт пишием, а за ним порядковый номер записи, таким образом можно увеличить количество перезаписей в (объём_eeprom/2) раз.

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

Ячейки таблицы сбоиных адресов например расположим вначале ЕЕПРОМА а
данные будем писать с конца (адрес уменьшая)

Таблица будет рости поэтому ее размер нада ограничить
(например если 25% сбоиных - все ФАТАЛ ЕРРОР )

Таблича будет писаться редко (по 1-й записи на 1 адресс) поэтому сбоев недолжнобыть =)

Если таблица и сбойнет (1 адресс) это приведет к неиспользованию какогото адреса в ЕЕПРОМЕ
(верефикация после записи всеравно отловит ошибку и данные неповредяться)

Меня беспокоит один вопросс:

Действительно ли ячейки ЕЕПРОМА умирают по одной ???
Опыта в этом деле нету поэтому будем ставить эксперимент и палить контроллеры =)

ну раз такое количество перезаписей то почему EEPROM? дык можно микромощную ram прикрутить с литиевой батареей

Всё зависит от цены, размеров и прочих требований.
RAM с батарейкой дороже, недолговечнее и, на мой взгляд, менее надёжно.
FRAM ещё дороже.

Небольшое исправление - я немного напутал в описании проблемы. Адрес ячейки - 0х004, а содержимое - вместо постоянного 0х04 - 0х04, 0х05, 0х0D.

Ответы:
1. По питанию всё нормально, сегдня проверяли.
2. Чтение при штатной работе производится только раз - по включению питания. Данные сохраняются в переменных.
3. Прерывание используется только по UART-у. Обработчик выставляет только признак получения данных. Сам анализ, как и обработка в теле программы (while (1) :о) ).
4. Перепроверил EEPROM через прорамматор, та же фигня, сбоящая ячейка 0х004. Несколько раз считывал, потом сверял содержимое файлов.

Саппорт всё так же молчит :о(.

В принципе проблему обошёл - перевёл на ячейку 0х00А. Но спортивный интерес остался - в решаемой задаче без EEPROM-а не обойтись.

to DeXteR
-----------------------
идея интересная :о), но боюсь муторная немного... У Petka - интересней. ИМХО.

В Application Note AVR101. описано ИМХО подобное решение. Там в EEPROM создаются два кольцевых буфера c одинаковым количеством уровней, в один записывается сохраняемый параметр, во второй индекс текущего уровня первого буфера… В результате максимальное количество циклов записи в EEPROM составляет 100000*N, где N-количесво уровней буферов…Кстати там и пример на С прилагается.

чтение-запись баита в EEPROM выглядит у меня :
- EEADR = 0 всегда
- перед записи сравниваю содаржимое ячеики, если то же самое, записи не будет

U8 ReadEEPROMByte( U16 Address )
{
U8 Data;
while( (EECR & __BIT_MASK( EEWE )) != 0 ) ;
EEAR = Address;
SetBit( EECR, __BIT_MASK( EERE ) );
Data = EEDR;
EEAR =0;
return Data;
}



void WriteEEPROMByte( U16 Address, U8 Data )
{
while( (EECR & __BIT_MASK( EEWE )) != 0 ) ;
if ( ReadEEPROMByte( Address ) != Data )
{
EEAR = Address;
if (( SREG & 0x80) !=0)
{ _CLI();
EEDR = Data;
SetBit( EECR, __BIT_MASK( EEMWE ) );
SetBit( EECR, __BIT_MASK( EEWE ) );
_SEI();
}
else {
EEDR = Data;
SetBit( EECR, __BIT_MASK( EEMWE ) );
SetBit( EECR, __BIT_MASK( EEWE ) );
}
EEAR =0;
}
}

Дело в том что я пишу на АСМ
поетому просто выдрать код - неполучиться.

В ЕЕПРОМЕ размещены счетчики
Младшие разряды обновляются чаще старших.

Поэтому для них эти уровни никчему (APNOTE)

Мой вариант эфективнее использует память
К томуже и быстродействие выше.

Если писать надо часто, лучше использовать FRAM от RAMTRONa с I2C или SPI интерфейсом. Задержек нет, ресурс огромный

А одни мои знакомые извратились до того, что стали писать-читать с тройной избыточностью, используя классическое мажоритирование. По их словам, за пять лет ни одного сбоя. Правда, возможно и без мажоритирования не было бы ни одного сбоя ) Кстати, интересна статистика, а как именно "вылетают" ячейки? Типа одно-несколько "нехороших" мест, или целый ряд близкорасполеженных?? По-любому, все проблемы начинаются с качества питания, imo.

Статистику раскажу как толька заказаный контроллер получу
Буду в цикле писать и жечь еепромку ему =(

Расскажите про классическое мажоритирование
Это как ??




Говорили уже - дорого + фиг я в Одессе куплю ее просто Недели 3 ждать придеться =(

Я слышел что если ФРАМУ коротнуть ноги питания он благополучно все забудет =(
НЕЗНАЮ ПРАВДА ЛИ ЭТО - кто работал - подскажите плиз

Не забудет. Враки всё это.
Работаю с ней давно и ничего подобного не замечал.

Пишем сразу в три ячейки (причем разнесенные в пространстве памяти), читаем из трех ячеек, принимаем решение - прочитали три одинаковых числа - ОК, прочитали два одинаковых, одно неодинаковое - принимаем решение в пользу двух одинаковых. Прочитали все три неодинаковых - кричим "караул!"

а ещё лучше мажорировать побитно!

Есче про мажоритирование, если кто захочет связываться, канечна. Оффсеты рекомендуется брать нечетными и взаимно простыми, при записи/чтении чураться значений x00 и xFF (что требует некоторой изворотливости, но весьма себя окупает), - ну и, само-собой, контрольна сумма тоже считается

Вариант с внешней еепром не расматриваете? Если и в ней будут сбой, то стабильность работы мк, правильность кода.

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

Более 3х лет это конечно хорошо
Расскажите пожалуйста Как часто пишеться ЕЕПРОМ
Сдесь говоилось о повышение ресурса а не надежности процесса записи - чтения

По своей проблеме. Ситуация интересная - по снятию питания кондёры еще держат напряжение около 5с. Уровень напряжения ещё достаточен для работы логики EEPROM, но уже без самого ядра МК. Здесь важно следующее - у EEPROM нет жесткой привязки к адресу, физически адрес 0х06, например, при каждом цикле вкл/выкл располагается где угодно :о) /шутка/. Это сделано для повышения ресурса и для уменьшения "загрязнения" самой памяти.
А сбой происхоит на цыкле выкл/вкл. когда возникает неопределённость между адресацией к EEPROM в ядре МК и обвязкой самого EEPROM.

Вот...
to DeXteR - мне кажется, что если у тебя посыпется EEPROM то картина будет такой же как и у меня.

P.S. Спасибо за участие, у вас тут интересно :о))

Блин. Если не нужно чтобы что то работало когда мк остановлен, то ресет должен быть общий. Функция у супервизора такая: обеспечивать необходимые временные задержки при подачи, провале питания и ОДНОВРЕММЕНО СБРАСЫВАТЬ ВСЕ МС, К НЕМУ ПОДКЛЮЧЕННЫЕ! Если нет входа ресета у микрухи, то резисторы поддяжки, притяжки или ресет на управляющий вход (если логика работы микрухи позволяет).

У меня вопросс какраз не в том как избежать ошибок - тут методов множество
А в том как увеличить рессурс EEPROM до 1 000 000 000 циклов перезаписи

Данные в ЕЕПРОМ намного важнее стабильной работы устройства на МК

Последнее время больше привлекает вариант с ФРАМ

a ja ne ponimaju komu nado 1000 000 000 tsiklov zapisi v EEPROM.
srednii EEPROM imeet tsikl zapisi 5mS. umnozajem,
polutsajem 5000 000 sek na bait. esli nado pisat 1024 bait, polutsajem 160 let
tolko na zapis. sto-to y vas s algoritmom ne optimalno.

Представь себе игровой автомат типа ЛОХОТРОН =)
Игроки кидают туда монетки гдето 20 000 в день
Нада все учитывать + сохранять в реальном времени ато злобный админ может научиться коротить батарейку и иметь себе левый неучтенный доход =)

Это блин не я а заказчит хочет =(

Если устраевает внешняя ЕЕПРОМ, то лучше переплатит 1$ и поставить FRAM от RAMTRON, ветка была чуть ниже на его обсущнее, тот же SPI или I2C, только ресурс не заканзивается (3-х вольтовая) или 10^10 (5-ти вольтовая). Размер уже до 512x8 кБит ожидается его увеличения. 10 лет хранения информации без питания. Корпус SOIC8, места на плате не займёт, а програмно намучаться можно с алгоритмами аж бегом, а про надёжность програмную или аппаратную, то я с клоняюсь к аппаратной, на программу 100% работоспособность ты не даш.