Доброе время суток, всезнающий ALL. Столкнулся я с печальной проблемой и нуждаюсь в каких-либо новых мыслях т.к. свои уже иссякли.
Имеется серийный девайс (некий интеллектуальный датчик, установленный на некоем транспортном средстве в огромном количестве). Собран на чипе mega88pa, связан с бортовым компьютером весьма длинной сетью, запитан (после защитных ограничителей в компьютере, разумеется) от линейника, 5 вольт, емкости - электролит что-то около 47-100 мкф и мелкая керамика, кажись 1 мкф. Супервизора нету, но БОД включен, данные гонятся по 485 (без опторазвязки).
Суть проблемы: у датчиков иногда напрочь убиваются настройки. Что характерно - датчики хворают не по одиночке, а сразу толпами. Настройки хранятся в EEPROM. В нескольких копиях. Каждая со своей 16-битной контрольной суммой, в случае порчи какой-либо из копий данные восстанавливаются из уцелевших. И фиг бы с настройками-калибровками, да там же хранятся сетевые адреса. Когда датчик не находит ни одной живой копии настроек - он грузит значения по умолчанию, в том числе и сетевой адрес, что приводит к полной свалке и частичной потери контроля.
Операции с EEPROM производятся редко (чтение при загрузке, плюс весьма редкая запись: перекалибровка при значительном уходе параметров электроники). Прерывания при этом запрещаются.
Межу сеансам работы с EEPROM указатель адреса устанавливается в ноль; блоки данных идут не с начала адресного пространства и разнесены между собой.
Код перечитан стопиццот раз, модуль работы с настройками весьма прост, неоднократно прогнан в эмуляторе с самыми разными условиями и эмуляцией различных сбоев памяти.

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

Есть какие-нибудь идеи, что еще можно проверить?...

Иголочки по питанию или мощная радиопомеха. Вы бы схемку показали и печатку ...
P.S. Как вариант - хранить настройки не только у себя, но и у "соседей", и при аварии запрашивать у них свои настройки. Или реализовать иной механизм назначения и контроля адресов, вроде механизма энумерации в USB. Но это не есть гут. Нужно искать причину проблемы и устранять ее ...

Есть идея. У меня что-то подобное было с AT90S2313 - периодически забывала всё, что было записано в EEPROM. А записан там у меня был личный идентификатор пользователя, обеспечивающий единство работы программы и устройства (при несовпадении не работало ни то, ни другое). В конце концов забывчивость EEPROM настолько меня доканала, что я стала пробивать идентификатор пользователя во флешь, а EEPROM-ом вообще перестала пользоваться. После чего проблему, как рукой сняло, а недоверие к EEPROM осталось на всю жизнь.

И лишь годы спустя я поняла причину этой неполадки. Она возникает из-за "чтения при загрузке". Т.е. тогда, когда напряжение питание только поднялось до уровня, когда bodlevel разбудил МК, но недостаточно для того, чтобы EEPROM работал устойчиво. Согласно даташита, "Write Pulse (Active low)", а потому при недостатке питания чтение из EEPROM порой превращаеться в запись (не хватило уровня WR). После запуска не торопитесь, потяните время, - подождите секунду другую прежде, чем обращаться к EEPROM.

P.S. То же самый совет относится и к калибровке (внешних) АЦП. Напряжение питания еще не устаканилось, а МК, ведомый дурацкой программой, уже полез АЦП калибровать .

BOD включать надо...
И питание мониторить...

Надо. Только не было у AT90S2313 этого Бода. Боды у АВРок позже появились.
С мониторингом питания аналогично - нет у этого МК собственного АЦП, а потому и мониторить по-простому не удается. А схему усложнять задним числом было мне нельзя.

Неотловленный косяк в программе, если это действительно "толпами".
Со времен помянутой Ксенией АТ90хх серии не встречал хулиганящих EEPROM. Ни разу за 9 лет.
PS BOD включен всегда. Почти всегда - 4.3 вольта. Может, в этом причина. 2.7 - очень редко.

Во! Нашла в даташите:

Preventing EEPROM Corruption
During periods of low VCC, the EEPROM data can be corrupted because the supply voltage is too low for the CPU and the EEPROM to operate properly. These issues are the same as for board level systems using EEPROM, and the same design solutions should be applied.
An EEPROM data corruption can be caused by two situations when the voltage is too low. First, a regular write sequence to the EEPROM requires a minimum voltage to operate correctly. Secondly, the CPU itself can execute instructions incorrectly, if the supply voltage is too low.
EEPROM data corruption can easily be avoided by following this design recommendation:
Keep the AVR RESET active (low) during periods of insufficient power supply voltage. This can be done by enabling the internal Brown-out Detector (BOD). If the detection level of the internal BOD does not match the needed detection level, an external low VCC reset Protection circuit can be used. If a reset occurs while a write operation is in progress, the write operation will be completed provided that the power supply voltage is sufficient.

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


Была такая идея. Не судьба, к сожалению. При разработке девайса поэкономили, а потом заказчик требовал новой функциональности. В итоге на данный момент у меня осталось два (2!) свободных слова в программной памяти. Да и с доступными для записи зонами у х8 не совсем удобно.
Можно было бы где-то выкроить одну страничку программной памяти после основного кода, хранить адрес там и сделать его записываемым только командами бутлоадера, это бы решило проблему. Но это уже система кривых зеркал, да и возможности обновить бут нету, а на существующих датчиках дыру надо как-то попытаться залатать.
Следующие серии будут уже на другом камне.


Спасибо за наводку, сам бы не обратил внимания ) Но в данном случае проблема явно не в этом - питание всё-таки 5В, БОД-уровень 4.3, да и даже в этом случае затиралась бы только первая копия данных т.к. чтение каждой копии достаточно долгое чтобы питание успело подняться и устаканиться.


После того как проблема проявилась первый раз весь модуль чтения-проверки-записи настроек был переписан с нуля, как сама методика так и реализация. Проблема осталась. "Толпами" в данном случае - из, допустим, 60 датчиков ВДРУГ заболели амнезией 14.
Проблемы с EEPROMом за последние два года возникали дважды: в первый раз оказалось что приборы просвечивали рентгеном, второй - пришла партия процов с "дырками" в EEPROMе (отдельные байты в перманентном нуле. Как будто бы пробой произошел).

ПС Обнаружили одно характерное сходство. В обоих случаях возникновения сбоя специфика работы датчиков такова, что внешние прерывания приходят от 480 и более раз в секунду. Возможно, это как-то связано (хотя, напоминаю, на время сохранения данных прерывания запрещаются).

А с радиационной обстановкой всё в порядке? Не то мож гамма-лучами по чипам проехались...

1) В программе есть чтение EEPROM в прерывании. Результат - во время записи из основного цикла может писать куда угодно.
2) Неверная схемотехника/разводка и как результат сбой МК по коротким импульсным помехам. Тут камень иногда может делать все что вздумается...


Вряд-ли. После такого не только содержимое ЕЕПРОМ, но и памяти программ желает долго жить.

1) неа. Во время инициализации настройки кэшируются в оперативную память и дальше работа с ними идет только оттуда.
2) хз. Учитывая что их там целая толпа, питание общее (+12. В каждом датчике стоит свой ограничитель+линейник+конденсаторы), а линии данных не имеют гальванической развязки, теоретически может конечно что-то по земле пролазить. Как я уже говорил, на схемотехнике малость сэкономили.

На счет радиации у меня уже была шизофреническая идея, на правах шутки, что у них там где-то геодезический маячок валяется и они по нему иногда ездят. Хотя если говорить серьезно, ИМХО, если облучать запитанный чип имеющий такое количество полевиков - он не память потеряет, а кубометр зловонного дыма испустит.

Вот линия на 750 киловольт там есть, да.

Ну, тогда у меня вторая попытка. Вы прерывания на время общения с EEPROM запрещаете? Если нет, то вы сами себе злобный Буратино.
Выглядеть должно примерно так:

т.е. ожидать окончание операции можно уже с включенными прерываниями, и грузить данные тоже, но на время работы с регистром EECR прерывания должны быть блокированы.
Сама я большого смысла в блокировании прерываний тут не вижу, однако помогает.

P.S. Вот еще что. Перед обращением к EEPROM желательно сделать
__watchdog_reset();
А то вдруг времени не хватит?

а смысл блокировки прерываний в том, что бит EEMPE сбрасывается железом через 4 такта после установки, и если между его установкой и устрановкой EEPE произойдет прерывание - к моменту возврата он будет уже сброшен и цикл записи не произойдет.

есть подобная проблема с еепром, особенно при медленном нарастании напряжения питания. столкнулся на м48, м88 и который с добавкой PA. для нормальной работы ввел задержку после запуска перед обращением к еепром. иначе FF читались.

По всей видимости тему можно закрывать.
Откопали прототип датчика на MEGA88 (под который изначально была эта разработка) - на нем такой проблемы нету, идентичные датчики на 88PA при тех же условиях иногда впадают в шизофрению. Пока решили сделать стопку прошивок с константными адресами, более кошерного выхода я не вижу.