Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Изменение ячеек EEPROM при снижении питания
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > MCS51, AVR, PIC, STM8, 8bit
Alt.F4
Не хватило Flash-памяти МК, решил отвести под константы EEPROM. Но читал, что существует вероятность разрушения ячеек памяти при критическом снижении питания. Причины пишут, мол CPU начинает вести себя неадекватно.
Вопрос: если в программе происходит только чтение EEPROM, функций записи нет, то возможно ли разрушение ячеек памяти при снижении питания?
Спасибо.

з.ы. я так понимаю "неадекватное" поведение CPU, это когда он начинает беспорядочно выполнять команды, таким образом, если в программе нет команд записи в EEPROM, то она и повредится не может, или я не прав?
stells
Цитата(zhevak @ May 28 2008, 00:03) *
... изменяетса ячейка, на которую указывает EEAR... Поскольку при включении в EEAR заносится нулевой адрес, то получается, что повреждается содержимое именно нулевого байта.

В свое время у меня так колбасило AT90S2313. Потом TINY2313. Причем, прога записью в EEPROM не занималась вообще, только читала...

V_G
Цитата(Alt.F4 @ Oct 11 2010, 20:43) *
Вопрос: если в программе происходит только чтение EEPROM, функций записи нет, то возможно ли разрушение ячеек памяти при снижении питания?

Вряд ли. Включите BOD, если беспокоитесь, но у меня и при отключенном ничего не портится.
ViKo
А если при снижении питания микроконтроллер скакнет куда-нибудь в область данных, где случайно окажется последовательность, приводящая к записи в EEPROM?
Чтобы этого не случалось, достаточно повесить на вход сброса супервизор питания. Или, как говорили BOD.
demiurg_spb
Цитата(V_G @ Oct 11 2010, 14:47) *
Включите BOD, если беспокоитесь, но у меня и при отключенном ничего не портится.
Вы ещё попляшетеsad.gif

Цитата(Alt.F4 @ Oct 11 2010, 13:43) *
если в программе происходит только чтение EEPROM, функций записи нет, то возможно ли разрушение ячеек памяти при снижении питания?
Да.
V_G
Цитата(demiurg_spb @ Oct 14 2010, 01:45) *
Вы ещё попляшетеsad.gif

Я пляшу на авр-ах 10 лет с нормальными тиражами. А до того - на 48 и 51 лет 15. Хорошая разводка платы, правильные блокировки - все, что нужно, чтобы достойно встретить старость!
demiurg_spb
Цитата(V_G @ Oct 14 2010, 09:56) *
Я пляшу на авр-ах 10 лет с нормальными тиражами.
На везение сослаться сложновато.
И тем не менее, нет никакой гарантии, что это случится или случалось, в Вы не замечаете.
То что вам сходило с рук не может служить руководством к действию для других участников.
Без обид!
rx3apf
Цитата(demiurg_spb @ Oct 14 2010, 13:58) *
На везение сослаться сложновато.
И тем не менее, нет никакой гарантии, что это случится или случалось, в Вы не замечаете.

Да, тут можно наступить... Сейчас в некоторых изделиях у нас наблюдается загаживание области EEPROM данных, причем не один-два байта по EEAR, а врассыпную, причем таким содержанием, которым просто я бы не смог загадить несанкционированным вызовом программы записи блока. И наблюдается это именно при каких-то флюктуациях питания (питание от USB через LDO, при пропадании сетевого питания хоста). AVmega168, BOD включен, естественно. И пока даже не очень понятно, с какой стороны это раскапывать...
xemul
Цитата(rx3apf @ Oct 15 2010, 13:03) *
Да, тут можно наступить... Сейчас в некоторых изделиях у нас наблюдается загаживание области EEPROM данных, причем не один-два байта по EEAR, а врассыпную, причем таким содержанием, которым просто я бы не смог загадить несанкционированным вызовом программы записи блока. И наблюдается это именно при каких-то флюктуациях питания (питание от USB через LDO, при пропадании сетевого питания хоста). AVmega168, BOD включен, естественно. И пока даже не очень понятно, с какой стороны это раскапывать...

Когда столкнулся с подобным на PIC (правда, давно было, сейчас такого не замечал; встроенный BOD не спасал, проблема была описана в каких-то ерратах Майкрочипа и полечена в следующих ревизиях чипов), пришлось поставить внешний супервизор на 4.5 В и завести его на отдельную ногу, тупо блокируя в программе любые новые обращения к ЕЕПРОМ, и поднять ёмкость по Vcc, чтобы гарантированно завершить начавшуюся запись.
Палыч
Цитата(rx3apf @ Oct 15 2010, 13:03) *
... наблюдается загаживание области EEPROM данных, причем не один-два байта по EEAR, а врассыпную, причем таким содержанием, которым просто я бы не смог загадить несанкционированным вызовом программы записи блока .... И пока даже не очень понятно, с какой стороны это раскапывать...
Следует напомнить, что flash (в частности, EEPROM - как более "нежная") может "загаживаться" не только при снижении питания при отключенном BOD, но и при кратковременном превышении питания выше некоторого порога (6,2 или 6,3В - на память не помню). В зависимости от значения напряжения и длительности выброса наблюдается стирание целиком, отдельных байтов или даже отдельных битов. Причем, в этом может быть повинен как блок питания, так и мощное оборудование, расположенное где-то неподалёку. Приходилось наблюдать жуткие помехи (амплидудой 1,5В и практически нулевой - померить ничем не удалось - длительности) от огромного токарного станка высотою в двухэтажный дом с тиристорным приводом, расположенного в соседнем цехе.
demiurg_spb
Цитата(rx3apf @ Oct 15 2010, 13:03) *
И пока даже не очень понятно, с какой стороны это раскапывать...

Пальцем в небо:
1. Пин AVCC подключен? BOD питается от AVCC...
2. Ёмкости по питанию везде установлены?
3. Как настроен SUT, CKSEL, CKOPT?
4. CKDIV'ом пользуетесь?
5. Питание раведено звездой от одной точки и нет контуров и общих токов?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.