Первый раз на 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 - интересней. ИМХО.