Форум РадиоКот

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

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

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

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

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

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

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

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

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

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

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

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

Viper115 писал(а):Где собака порылась?

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

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

urry писал(а):это нормально

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

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

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

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

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

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

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

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

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

woddy писал(а):что при чтении - тоже самое

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

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

Dmitry Dubrovenko писал(а):

woddy писал(а):что при чтении - тоже самое

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

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

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

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

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

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