| |
 самопроизвольная модификация EEPROM |
|
|
|
|
 May 27 2008, 18:49
|
Участник
Группа: Свой
Сообщений: 56
Регистрация: 12-04-06
Из: Haifa
Пользователь №: 16 042
|
Цитата(stells @ May 27 2008, 21:43)  при отключении/включении питания происходит изменение содержимого EEPROM в tiny26... было предположение, что на одном из входов АЦП в этот момент присутствует отрицательное напряжение, поставил диод - не помогло. где искать причину? Добрый вечер. Не знаю как в tiny26 но в Мега 16, 32 первая ячейка EEPROM может измениться при включении/выключении источника питания. Поэтому там советуют не хранить информацию.
|
|
|
|
|
|
|
|
May 27 2008, 20:03
|
Знающий
Группа: Свой
Сообщений: 723
Регистрация: 29-08-05
Из: Березовский
Пользователь №: 8 065
|
Цитата(stells @ May 28 2008, 00:57) и BOD не включен, и данные изменяются именно в 1-й ячейке, в остальных вроде нормально все... уже большое спасибо!  могут быть еще какие-то варианты? Я немного уточню. Изменяется не совсем первая ячейка, изменяетса ячейка, на которую указывает EEAR. (К стати, было бы более правильно говорить не о первой ячейке, а о байте, находящемуся по адресу 0х00 -- нулевом байте.) Поскольку при включении в EEAR заносится нулевай адрес, то получается, что повреждается содержимое именно нулевого байта. В свое время у меня так колбасило AT90S2313. Потом TINY2313. Причем, прога записью в EEPROM не занималась вообще, только читала. А через некоторое время я где-то прочитал про этот глюк. (Уже я не помню где, не важно.) Там рекомендовали не использовать нулевой байт. Но мой бывший работодатель -- парень, которого еще поискать надо -- умудрался портить и последующие байты. Как он подключал мои девайсы, это отдельная песня. Сноп искр! Свидетелей выносили ногами вперед... После чего, я решил, что после любых операций с EEPROM, в EEAR записывать нулевой адрес. Ну и, разумеется, нулевой байт не использовать вообще. После этого глюков больше не наблюдалось. Странно, я думал, АТМЕЛ уже давно победил этот глюк. 
--------------------
Хочешь рассмешить Бога -- расскажи ему о своих планах!
|
|
|
|
|
|
|
|
May 27 2008, 23:14
|
Гуру
Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095
|
Цитата(zhevak @ May 27 2008, 23:03) Странно, я думал, АТМЕЛ уже давно победил этот глюк. Как бы да. Рекомендовав либо включать внутренний супервизор, либо использовать внешний. Но: Цитата(stells @ May 27 2008, 21:57) и BOD не включен, - Грррр шмяк... - сказала японская лесопилка. - Ну дык, еб тыть! - сказали суровые русские мужики и пошли валить лес двуручными пилами.
--------------------
На любой вопрос даю любой ответ"Write code that is guaranteed to work, not code that doesn’t seem to break" ( C++ FAQ)
|
|
|
|
|
|
|
|
May 28 2008, 05:38
|
Частый гость
Группа: Новичок
Сообщений: 100
Регистрация: 5-03-07
Пользователь №: 25 892
|
Цитата(stells @ May 27 2008, 22:57) и BOD не включен, и данные изменяются именно в 1-й ячейке, в остальных вроде нормально все... уже большое спасибо! могут быть еще какие-то варианты? Еще как есть. Вот когда решите все эти детские проблемы, останется одна взрослая - на всё время цикла записи в EEPROM нужно гарантированно поддерживать Vdd хотя бы в пределах допустимого минимума. Ни BOR, ни внешний супервизор сами по себе тут не помогут.
|
|
|
|
|
|
|
|
May 28 2008, 05:53
|
внештатный сотрудник
Группа: Участник
Сообщений: 2 458
Регистрация: 10-05-08
Из: МО, Медвежьи озера
Пользователь №: 37 401
|
Цитата(blackbit @ May 28 2008, 09:38) Еще как есть. Вот когда решите все эти детские проблемы, останется одна взрослая - на всё время цикла записи в EEPROM нужно гарантированно поддерживать Vdd хотя бы в пределах допустимого минимума. Ни BOR, ни внешний супервизор сами по себе тут не помогут. цикл записи в EEPROM у меня происходит по нажатию кнопки, так что если пользователь не решит одновременно с записью отключить питание, то эта проблема не должна по идее проявиться... спасибо! кстати видимо и BOD тут не при чем, скорее всего проблема именно в том, что модифицируется только нулевая ячейка... так что в японской бензопиле просто бензин кончился
Сообщение отредактировал stells - May 28 2008, 06:00
|
|
|
|
|
|
|
|
May 28 2008, 05:57
|
Местный
Группа: Свой
Сообщений: 426
Регистрация: 5-04-07
Из: Санкт-Петербург
Пользователь №: 26 782
|
Цитата(stells @ May 27 2008, 22:43) при отключении/включении питания происходит изменение содержимого EEPROM в tiny26... было предположение, что на одном из входов АЦП в этот момент присутствует отрицательное напряжение, поставил диод - не помогло. где искать причину? Проблема стара как AVR, IAR, например, давным давно не использует 0-ую ячейку ЕЕПРОМ за счет настроек XCL файлов. Сам Атмел рекомендует внешний супервизор, либо БОД для относительно новых моделей.
|
|
|
|
|
|
|
|
May 28 2008, 09:28
|
Группа: Свой
Сообщений: 1 928
Регистрация: 11-07-06
Пользователь №: 18 731
|
Цитата(stells @ May 28 2008, 09:53) кстати видимо и BOD тут не при чем, скорее всего проблема именно в том, что модифицируется только нулевая ячейка... Просто поверьте/запомните, что при использовании EEPROM хотя бы на чтение нужно снабдить контроллер каким-либо супервизором питания (внутренним или внешним - это уже от задачи). Без этого, как уже отметили, может запороться та ячейка EEPROM, на которую смотрит регистр адреса в момент просада питания. Частичное решение проблемы при неприятии супервизоров по религиозным мотивам: - не обращаться к EEPROM во первых строках программы (делайте таймаут на время установления напряжения(-ий) питания контроллера); - по завершению работы с EEPROM устанавливать регистр адреса на неиспользуемый адрес. Заметьте, что я нигде не упомянул AVR ввиду универсальности проблемы и ее решения.
|
|
|
|
|
|
|
|
May 28 2008, 18:13
|
внештатный сотрудник
Группа: Участник
Сообщений: 2 458
Регистрация: 10-05-08
Из: МО, Медвежьи озера
Пользователь №: 37 401
|
Цитата(Nanobyte @ May 28 2008, 21:57) Да, вот ещё есть малые сапёрные грабли (те, что по пояс ). На время записи в EEPROM лучше будет запретить прерывания, если конечно они используются. Как-то я очень весело провёл почти сутки в поисках сбоев процесса калибровки прибора по этой причине. да, прерывания запрещены... в принципе я вроде как решил этот вопрос, сначала перестал использовать нулевой байт - ситуация улучшилась, но в конце концов сбой поймал-таки, потом BOD включил и пока все нормально... спасибо большое!
|
|
|
|
|
|
|
|
May 29 2008, 11:13
|
Местный
Группа: Участник
Сообщений: 322
Регистрация: 21-06-07
Из: СНГ
Пользователь №: 28 596
|
Цитата(demaven @ May 29 2008, 13:56) в 16 меге ЕЕПРОМ слетала при сбоях питания и при внутреннем, и при внешнем визоре, причем портилась не только 0-вая ячейка. питание было сильно шумным и побороть этот шум не удавалось, пришлось ставить внешнюю память тоже изредка наблюдается у меги 8 в моём проекте... питание от USB. Слетает вся память полностью... МК пишет/читает епром по требованию от ПК. сам МК в неё не лезет... чтение епрома сильно не часты...
--------------------
|
|
|
|
|
|
|
|
May 29 2008, 14:24
|
дятел
Группа: Свой
Сообщений: 1 681
Регистрация: 13-05-06
Из: Питер
Пользователь №: 17 065
|
Цитата(Nanobyte @ May 28 2008, 21:57) Да, вот ещё есть малые сапёрные грабли (те, что по пояс ). На время записи в EEPROM лучше будет запретить прерывания, если конечно они используются. Как-то я очень весело провёл почти сутки в поисках сбоев процесса калибровки прибора по этой причине. На все время записи ? ИМХО, это ерунда, запрещать нужно только на время спецпоследовательности запуска записи, иначе 1,8-8,5мс (зависит от чипа) прога не может ничем заниматься, запрещение прерывания на все время записи это костыль который скрывает ошибки в проектировании проги.
|
|
|
|
|
|
|
|
May 29 2008, 16:01
|
внештатный сотрудник
Группа: Участник
Сообщений: 2 458
Регистрация: 10-05-08
Из: МО, Медвежьи озера
Пользователь №: 37 401
|
Цитата(singlskv @ May 29 2008, 18:24) На все время записи ?
ИМХО, это ерунда, запрещать нужно только на время спецпоследовательности запуска записи,
иначе 1,8-8,5мс (зависит от чипа) прога не может ничем заниматься,
запрещение прерывания на все время записи это костыль который скрывает ошибки в
проектировании проги. наверное Вы правы... главное проверить в подпрограмме обработки прерывания завершилась ли предыдущая запись (если надо что-то писать), а так прерывание не должно повлиять на результат записи... может он не это имел ввиду?
|
|
|
|
|
|
|
|
May 29 2008, 16:15
|
дятел
Группа: Свой
Сообщений: 1 681
Регистрация: 13-05-06
Из: Питер
Пользователь №: 17 065
|
Цитата(stells @ May 29 2008, 20:01) наверное Вы правы... главное проверить в подпрограмме обработки прерывания завершилась ли предыдущая запись Да, именно так, проверили и если еще не закончилась ушли заниматься другими делами... Цитата (если надо что-то писать) Если запрос на запись возникает спонтанно(те в практически в любой момент времени), тогда нужно организовать очередь из запросов. Цитата , а так прерывание не должно повлиять на результат записи... может он не это имел ввиду? Не должно ни разу, проблемы могут быть только если очень часто пишем и очередь образовалась внушительная, типа если в одной и той же еще необработанной очереди может попасться две записи одного данного...
|
|
|
|
|
|
|
|
May 30 2008, 21:15
|
Гуру
Группа: Свой
Сообщений: 2 712
Регистрация: 28-11-05
Из: Беларусь, Витебск, Строителей 18-4-220
Пользователь №: 11 521
|
Цитата(QuickWitted @ May 29 2008, 14:13) тоже изредка наблюдается у меги 8 в моём проекте... питание от USB. Слетает вся память полностью... МК пишет/читает епром по требованию от ПК. сам МК в неё не лезет... чтение епрома сильно не часты... Это стопудовый программный хомут. У меня серийное изделие выпускается на м8 с питанием от USB. Перед ним стаял комплект из м8515+т2313 ну и так далее. Конфигурация этого прибора хранится в EEPROM. Причём так, что с вероятностью близкой к 100% если запортится, то изделие ко мне вернётся. И так уже много лет. Ну нет проблем! Просто нет. Единицы тысяч изделий.
|
|
|
|
|
|
|
|
Jun 1 2008, 05:14
|
Группа: Новичок
Сообщений: 12
Регистрация: 22-08-07
Пользователь №: 29 981
|
Аналогичная ситуация и именно с тини26
Слетают ячейки еепром то ли по включению, то ли по выключению - естественно, выяснить не удалось.
Все что выше советовалось, пробовал - вопрос в статистике.
собрал автомат - клацалку с периодом в 10 секунд. Более 2-х суток не выдерживала никакая идея.
Что помогло:
Значений мне надо сохраниять немного.
Каждое значение сохранил в 3-х местах.
По включению сравниваю считанные. Если 2 значения равны между собой, записываю его в 3-ю ячейку.
вылетов одновременно 2-х ячеек, относящихся к одной переменной, пока не наблюдалось (клацанье пошло уже на вторую неделю).
|
|
|
|
|
|
|
|
Jun 1 2008, 13:26
|
Группа: Новичок
Сообщений: 12
Регистрация: 22-08-07
Пользователь №: 29 981
|
Да BOR-то включен...
Я понимаю, 2 ячейки тоже вопрос времени. Но надеюсь, что время будет достаточно большим.
Но все остаьные меры, что я пробовал, существенно ситуацию не улучшали
|
|
|
|
|
|
|
|
Jun 2 2008, 12:12
|
Группа: Новичок
Сообщений: 12
Регистрация: 22-08-07
Пользователь №: 29 981
|
Верю, что причину найти было бы лучше.
Прблема,что сбои слишком редкие.
Проверка каждой идеи - день-два прогона.
Долбался, долбался, да и решил устранить последствие
|
|
|
|
|
|
|
|
Jun 2 2008, 15:21
|
Группа: Новичок
Сообщений: 12
Регистрация: 22-08-07
Пользователь №: 29 981
|
проверял на 3-х кристаллах. может партия неудачная. 0735
записывал сразу пакет из 6 байтов данных. после выключения-включения иногда один из битов может изменить состояние из 0 в 1.
расположение бита по этим 6 байтам произвольное. Поэтому думаю, что прямой связи адреса ЕЕПРОМ и потерянного данного нет. Кстати, ячейка с адресом, на который указывал регистр, портилась, пожалуй, пореже остальных...
|
|
|
|
|
|
|
|
Jun 2 2008, 16:57
|
внештатный сотрудник
Группа: Участник
Сообщений: 2 458
Регистрация: 10-05-08
Из: МО, Медвежьи озера
Пользователь №: 37 401
|
Цитата(Nickolya_K @ Jun 2 2008, 19:21) проверял на 3-х кристаллах. может партия неудачная. 0735
записывал сразу пакет из 6 байтов данных. после выключения-включения иногда один из битов может изменить состояние из 0 в 1.
расположение бита по этим 6 байтам произвольное. Поэтому думаю, что прямой связи адреса ЕЕПРОМ и потерянного данного нет. Кстати, ячейка с адресом, на который указывал регистр, портилась, пожалуй, пореже остальных... да... засада... не знаю, как у вас, а у меня прибор, в котором я использую tiny, скважинный и доступа к нему во время работы нет... поэтому и понять, что с ним происходит, невозможно... если будет проявляться такой эффект, то он будет просто гнать наверх ложную телеметрию...
|
|
|
|
|
|
|
|
Jun 2 2008, 17:47
|
кекс
Группа: Свой
Сообщений: 3 825
Регистрация: 17-12-05
Из: Киев
Пользователь №: 12 326
|
Цитата(SasaVitebsk @ Jun 2 2008, 20:18) BOD, согласно документа, выставлен на 2.7V.
....
11059200 полностью устранил проблему. Overclock все равно остался ;> Как-то по недосмотру зашили BOD 2.7В (вместо 4.0В) в партию девайсов (100 шт) с питанием 5В и частотой 11.0592. В девайсах есть особенность - быстрое нарастание и очень медленный спад питания. В одном из девайсом слетел блок eeprom через месяц работы причем слетел "по-взрослому", CRC8 проверка выдала "Ok" в, то время как данные запортились напрочь. В остальных 99 устройствах слетов не наблюдалось. Мораль байки: Atmel гарантирует работу на частотах до 8Mhz с питанием 2.7В, для частот выше 8Mhz и питании ниже 3В есть риск и неопределенность.
|
|
|
|
|
|
|
|
Jun 5 2008, 16:01
|
Местный
Группа: Свой
Сообщений: 446
Регистрация: 12-03-06
Из: Москва
Пользователь №: 15 142
|
Цитата(stells @ Jun 5 2008, 18:28) но тогда были бы и зависания, и прочие несанкционированные действия... В первом посте было про вкл/выкл. Какие еще возможны видимые действия за несколько первых/последних мс. Неоднократно пробовал выкинуть команды записи в EEPROM и сбои уходили . Ну ничем не собьешь. Только повышением напряжения до 9В В малополезности CRC EEPROM убеждался на чужих примерах, когда проверка CRC проходит, а данные странные. Это дополнительно говорит о сбое PC. Несколько помогало при борьбе с хилым генератором 90S2313 разнесение установки разрешения записи и собственно записи. Но на мегах таких проблем с полным размахом генератора нет.
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
