[stells 10]

при отключении/включении питания происходит изменение содержимого EEPROM в tiny26... было предположение, что на одном из входов АЦП в этот момент присутствует отрицательное напряжение, поставил диод - не помогло. где искать причину?

[dibor 0]

при отключении/включении питания происходит изменение содержимого EEPROM в tiny26... было предположение, что на одном из входов АЦП в этот момент присутствует отрицательное напряжение, поставил диод - не помогло. где искать причину?

 

Добрый вечер.

Не знаю как в tiny26 но в Мега 16, 32 первая ячейка EEPROM может измениться при включении/выключении источника питания.

Поэтому там советуют не хранить информацию.

[Nanobyte 0]

А BOD включен? Если нет, то именно эти проблемы и проявляются.

[stells 10]

и BOD не включен, и данные изменяются именно в 1-й ячейке, в остальных вроде нормально все... уже большое спасибо! :)

могут быть еще какие-то варианты?

[zhevak 0]

и BOD не включен, и данные изменяются именно в 1-й ячейке, в остальных вроде нормально все... уже большое спасибо! :)

могут быть еще какие-то варианты?

 

Я немного уточню. Изменяется не совсем первая ячейка, изменяетса ячейка, на которую указывает EEAR. (К стати, было бы более правильно говорить не о первой ячейке, а о байте, находящемуся по адресу 0х00 -- нулевом байте.) Поскольку при включении в EEAR заносится нулевай адрес, то получается, что повреждается содержимое именно нулевого байта.

 

В свое время у меня так колбасило AT90S2313. Потом TINY2313. Причем, прога записью в EEPROM не занималась вообще, только читала. А через некоторое время я где-то прочитал про этот глюк. (Уже я не помню где, не важно.) Там рекомендовали не использовать нулевой байт. Но мой бывший работодатель -- парень, которого еще поискать надо -- умудрался портить и последующие байты. Как он подключал мои девайсы, это отдельная песня. Сноп искр! Свидетелей выносили ногами вперед... После чего, я решил, что после любых операций с EEPROM, в EEAR записывать нулевой адрес. Ну и, разумеется, нулевой байт не использовать вообще. После этого глюков больше не наблюдалось.

 

Странно, я думал, АТМЕЛ уже давно победил этот глюк. :(

[Сергей Борщ 123]

Странно, я думал, АТМЕЛ уже давно победил этот глюк. :(

Как бы да. Рекомендовав либо включать внутренний супервизор, либо использовать внешний. Но:

и BOD не включен,

- Грррр шмяк... - сказала японская лесопилка.

- Ну дык, еб тыть! - сказали суровые русские мужики и пошли валить лес двуручными пилами.

[blackbit 0]

и BOD не включен, и данные изменяются именно в 1-й ячейке, в остальных вроде нормально все... уже большое спасибо! :)

могут быть еще какие-то варианты?

Еще как есть. Вот когда решите все эти детские проблемы, останется одна взрослая - на всё время цикла записи в EEPROM нужно гарантированно поддерживать Vdd хотя бы в пределах допустимого минимума. Ни BOR, ни внешний супервизор сами по себе тут не помогут.

[stells 10]

Еще как есть. Вот когда решите все эти детские проблемы, останется одна взрослая - на всё время цикла записи в EEPROM нужно гарантированно поддерживать Vdd хотя бы в пределах допустимого минимума. Ни BOR, ни внешний супервизор сами по себе тут не помогут.

цикл записи в EEPROM у меня происходит по нажатию кнопки, так что если пользователь не решит одновременно с записью отключить питание, то эта проблема не должна по идее проявиться... спасибо!

кстати видимо и BOD тут не при чем, скорее всего проблема именно в том, что модифицируется только нулевая ячейка... так что в японской бензопиле просто бензин кончился :)

Изменено 28 мая, 2008 пользователем stells

[VladimirYU 0]

при отключении/включении питания происходит изменение содержимого EEPROM в tiny26... было предположение, что на одном из входов АЦП в этот момент присутствует отрицательное напряжение, поставил диод - не помогло. где искать причину?

Проблема стара как AVR, IAR, например, давным давно не использует 0-ую ячейку ЕЕПРОМ за счет настроек XCL файлов. Сам Атмел рекомендует внешний супервизор, либо БОД для относительно новых моделей.

[xemul 0]

кстати видимо и BOD тут не при чем, скорее всего проблема именно в том, что модифицируется только нулевая ячейка...

Просто поверьте/запомните, что при использовании EEPROM хотя бы на чтение нужно снабдить контроллер каким-либо супервизором питания (внутренним или внешним - это уже от задачи).

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

Частичное решение проблемы при неприятии супервизоров по религиозным мотивам:

- не обращаться к EEPROM во первых строках программы (делайте таймаут на время установления напряжения(-ий) питания контроллера);

- по завершению работы с EEPROM устанавливать регистр адреса на неиспользуемый адрес.

 

Заметьте, что я нигде не упомянул AVR ввиду универсальности проблемы и ее решения.

[stells 10]

все понятно... спасибо за ответы! я и запись в нулевую ячейку убрал, и BOD включил - пока все нормально :)

[Nanobyte 0]

Да, вот ещё есть малые сапёрные грабли (те, что по пояс :) ). На время записи в EEPROM лучше будет запретить прерывания, если конечно они используются. Как-то я очень весело провёл почти сутки в поисках сбоев процесса калибровки прибора по этой причине.

[stells 10]

Да, вот ещё есть малые сапёрные грабли (те, что по пояс :) ). На время записи в EEPROM лучше будет запретить прерывания, если конечно они используются. Как-то я очень весело провёл почти сутки в поисках сбоев процесса калибровки прибора по этой причине.

да, прерывания запрещены... в принципе я вроде как решил этот вопрос, сначала перестал использовать нулевой байт - ситуация улучшилась, но в конце концов сбой поймал-таки, потом BOD включил и пока все нормально... спасибо большое! :)

[demaven 0]

в 16 меге ЕЕПРОМ слетала при сбоях питания и при внутреннем, и при внешнем визоре, причем портилась не только 0-вая ячейка. питание было сильно шумным и побороть этот шум не удавалось, пришлось ставить внешнюю память

[QuickWitted 0]

в 16 меге ЕЕПРОМ слетала при сбоях питания и при внутреннем, и при внешнем визоре, причем портилась не только 0-вая ячейка. питание было сильно шумным и побороть этот шум не удавалось, пришлось ставить внешнюю память

 

тоже изредка наблюдается у меги 8 в моём

проекте...

питание от USB. Слетает вся память полностью...

МК пишет/читает епром по требованию от ПК.

сам МК в неё не лезет... чтение епрома сильно не часты...