Attiny13 через раз сохраняет данные EEPROM!?

[Viper115]

Сталкиваюсь не в первый раз. Имеется устройство, которое управляет в авто яркостью ламп (ДХО). В EEPROM сохраняются данные скважности ШИМ и уровень ADC, при котором ДХО включаются. Так вот, при выключении питания EEPROM частично или полностью сбрасывается и данные не сохраняются.
Думал, что не записывается. Сделал в коде проверку записи: записал значение - считал его в другой регистр - сравнил оба регистра - если не равно, то опять повторить цикл записи. Пока программа крутится в цикле записи-проверки, установлена яркость 15% (исключительно дабы отследить, что программа крутится в цикле, пытаясь записать и проверить). Но по факту яркость до 15% визуально не падает, что свидетельствует о том, что цикл записи-проверки проходит без проблем.
Выключаю, включаю - не работает. Вытаскиваю тиньку, считываю EEPROM - частично есть данные, частично нет.
Ладно если бы постоянно не сохраняло, можно было бы на код грешить. А так, три раза из десяти только нормально работает.
Где собака порылась? Бракованные МК?

[woddy]

как часто идет запись? есть ли аппаратная проверка напряжения питания перед тем как производить запись?

если попытка записи происходит в момент выключения (напряжение питания ниже нормы), то данные с высокой вероятностью повреждаются

[Viper115]

Проверки напряжения нет. А есть в этом необходимость? Схема работает от 12В, на входе 100мкФ, 78l05, за ней еще две емкости: 0,1 и 100мкФ
Запись идет один раз во время работы. Захотели отключить автоматическое включение ДХО - поморгали трижды габаритами, ШИМ переключился в 0%, записали это значение и работаем дальше. Захотели откалибровать порог включения по напряжению - нажали кнопку, считалось ADC, записало в EEPROM и дальше работает.
Пока есть питание, все работает, как часы. Стоит выключить и запустить снова и за все берется его величество Случай

[woddy]

зачем проверять напряжение я написал выше. если идет запись а в этот момент пропадает питание - высока вероятность потерь данных.

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

кстати. чтение тоже может повреждать данные. потому после включения питания надо подождать: в идеале замерять напряжение, в крайнем случае тупая задержка на (???)миллисекунд, и лишь после этого читать EEPROM

[Martin76]

Выключаю, включаю - не работает. Вытаскиваю тиньку, считываю EEPROM - частично есть данные, частично нет.

А BOD выключен? BODLEVEL=11?

[Viper115]

Да, BODLEVEL в норме.
Прошил другой камушек - все работает. Судя по всему, бракованный МК. Кстати, далеко не первый((

[Viper115]

Да что такое! Этот тоже подглючивает. Намного реже, но тем не менее

[Dr. Alex]

Хм, да у вас, какая-то несовместимость с ТИНЬКАМИ)))))))

[Dmitry Dubrovenko]

Где собака порылась?

ИМХО, в программе.
Получается, что при выключении питания, происходит попытка записи.

[urry]

это нормально.
Прописываете в 3 местах, сохраняете с контрольной суммой, при включении сверяете, не пользуетесь начальными адресами, которые портятся чаще всего. Посмотрите, как сделано у меня
http://radiokot.ru/forum/viewtopic.php? ... 0#p1873380
За этот код меня уже обзывали параноиком. Но
(с) Если у вас паранойя, это еще не значит, что за вами не следят...

[Dmitry Dubrovenko]

это нормально

Юр, что нормально?
Что данные из EEPROM пропадают?
Я, конечно, не очень АВРы люблю, но такое первый раз слышу.

[urry]

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

[woddy]

обращаю внимание, что при чтении - тоже самое. а не только при записи.

я спросил ставил ли автор задержку при включении, но ответа не получил

[BOB51]

Есть вероятность зависимости "глюков" от построения программного кода (даже если вероятность правильности такого кодового решения подтверждает симулятор). С еепромкой особо баловаться не приходилось, а вот порты от казалось бы нормальной программы "чумели"...
См. http://radiokot.ru/forum/viewtopic.php? ... 0%BE%D0%BC
Спасло применение программных алгоритмов, перенесенных с MCS51...

[Viper115]

Еще раз повторюсь, что запись производилась НЕ в момент выключения. Да и перепроверка записи присутствует.
Задержки перед считыванием не было. Только инициализация и сразу после нее обращение к памяти. На всякий пожарный поставил задержку в 3 000 циклов, надеюсь достаточно. Пробовать буду уже завтра.

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

[Dmitry Dubrovenko]

Если в момент пропажи напряжения идет запись в епром

Это-то понятно.
Неужели у новых чипов встроенные супервизоры не помогают.
У меня (тьфу-тьфу-тьфу) ни разу не сбоило. Правда больше занимаюсь с ПИКами, чем с АВРами, и, кстати, стараюсь прежде, чем что-то писАть в EEPROM, считываю ячейку, и записываю только, если данные не совпадают.
А ты контрольную сумму на каждую ячейку пишешь, или CRC на блок? И какой?

что при чтении - тоже самое

Это с чего вдруг?

[BOB51]

Работа с EEPROM и /или командами класса SPM производится
ИСКЛЮЧИТЕЛЬНО
при
а - запрещенных всех видов прерываниях на время обращения в цикле записи (возможно и при чтении)
б - при штатной для данного МК тактовой частоте - эту "мелочь" надо внимательнейшим образом вычитывать по конкретному даташиту. Обычно за такую частоту принимается работа с внутренним RC генератором "по умолчанию", но возможны "вариации" в некоторых пределах.
У пиков подобный казус возможен только с моделями где имеется переключаемый "многочастотный" внутренний RC-генератор, но микрошип многократно перестраховывает свои изделия (в том числе и в множестве "ЕРРАТ" - жаль только , что методику чтения версии кристалла слишком уж "позаховали"), а вот атмели так совсем "пишут между строк"
Пример - если я после железного ресета загнал 13-ю в более высокочастотный диапазон изменением содержимого CLKPR, или применил частоту генератора 4,8 МГц вместо 9,6 МГц то МК вправе послать меня весьма далеко по отношению к вышеуказанным операциям.
(СМ. диаграмма Figure 6-1. стр. 23 документа 8126F–AVR–05/12 )
P.S.
Работал с АВР-ками и многократной перезаписью параметров в EEPROM для информационных табло без малейших дополнительных защитных мер - исключительно по даташиту и с применением RC-генератора "по умолчанию" (ATmega8515) - за более чем 2 года эксплуатации не одного сбоя.
Правда... программы писаны под ассемблером...

[woddy]

что при чтении - тоже самое

Это с чего вдруг?

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

[Dmitry Dubrovenko]

вникать нет желания, если честно. но пережевывалось на разных форумах многократно

Стандартный ответ, который заставляет сильно сомневаться в истинности аксиомы.

[zero648]

за более чем 2 года эксплуатации не одного сбоя.
Правда... программы писаны под ассемблером...

Пишу на ассемблере, с АВРми больше года, с ЕЕПРОМ проблем небыло никогда.