Tiny13, проблема с чтением EEPROM Опции

[Len_OK]

Есть электронный ключ на базе МК Tiny13. Данные ключа хранятся в EEPROM.
Проблема такая: после некоторого времени использования ключа EEPROM-ка периодически не читается, либо при чтении обнаруживаются изменённые данные! можно ли решить эту проблему?
Как защитить контроллер от статики,которая может наводиться на корпус ключа?

[defunct]

В моём случае (на мой взгляд) следующая ситуация : в определённые моменты времени уровень на линии RESЕT достигал низкого уровня, при этом по линиям MOSI, SCK могли проходить помехи которые и преводили МК в режим программирования.

Все это очень смущает. Почему тогда у вас не слетал Flash? Помеха была такой умной, что генерила только команду записи eeprom? Звучит абсурдно.
И не проще ли отключить reset в таком случае? Для восьминогой Tiny13 дополнительная ножка куда более актуальна чем вкл/откл ISP.

[mart-13]

Да ну бросте городить чушь. BOD надо включать, а не SPIEN смыкать, чтобы МК сбрасывался до того как питание упадет ниже критической отметки, после которой может изменяться содержимое RAM (регистр PC относится к RAM). А вот изменение содержимого RAM как раз может повлечь за собой прыжек на любой участок кода, в том числе и на участок где производится запись в eeprom. От того он у вас и слетал.

Для отладки Tiny13 вообще-то есть debugWire интерфейс, при включение которого ISP отключается автоматически.

1. Включить BOD.
2. Сделать запись помехозащищенной - разбить eeprom на два блока по 32 байта. Данные сохранять сразу в два блока, блоки защищать хотя бы CRC8. При слете данных в одном из блоков - брать данные из второго, и восстанавливать "сбойнувший" блок.


Все это очень смущает. Почему тогда у вас не слетал Flash? Помеха была такой умной, что генерила только команду записи eeprom? Звучит абсурдно.
И не проще ли отключить reset в таком случае? Для восьминогой Tiny13 дополнительная ножка куда более актуальна чем вкл/откл ISP.

На сколько я понимаю, даный форум был создан для того, чтобы люди смогли получить ответы на свои вопросы и поделиться опытом, а не слышать в свою сторону "несешь чушь"... Хотя Вы, уважаемый defunct и "Гуру", но с вашей стороны это мягко говоря неуважение к нам форумчанам.
Ну включили вы свой БОД, ну есть цитата в даташите:

EEPROM data corruption can easily be avoided by following this design
recommendation:
Keep the AVR RESET active (low) during periods of insufficient power supply voltage.
This can be done by enabling the internal Brown-out Detector (BOD). If the
detection level of the internal BOD does not match the needed detection level, an
external low VCC Reset Protection circuit can be used. If a reset occurs while a write
operation is in progress, the write operation will be completed provided that the
power supply voltage is sufficient.

Да в этом Вы правы, но, судя из моего опыта - это не всегда срабатывает...
В моем случае порча ЕЕПРОМ часто происходила в тех же случаях, что и у Kalina, и у Len_OK, создавшего эту тему, а именно в момент присутствия каких либо напряжений на Vcc и линиях SPI, при этом на Reset было 0В. Один мой знакомый даже отправлял письмо компании Atmel (которая, кстати изначально занималась только ЕЕПРОМ) с подобным вопросом, и получил ответ, который полностью совпадает с опытом Kalina - проблемы с SPI, конечно же при условии соблюдения всех остальных замечаний по поводу ЕЕПРОМ АВР-ов.

И во-первых: !!!Внимательно!!! читая данную тему я заметил, что Kalina работал с Мега8, а там вообще нету debugWire...
Во-вторых:на сколько я знаю для debugWire надобно заиметь не совсем простой программатор...
В-третьих:если Вы отключите Reset, то не сможете программировать по SPI и Вам снова придется заиметь не совсем простой программатор...
В-четвертых:может быть Вы посоветуете еще и кодировать сами записываемые данные кодами Хеминга, Грея и т. п. Что же у Вас за ключ такой получится???
В-пятых:сама компания Атмел гарантирует правильную работу при соблюдении всех правил использования ЕЕПРОМ, как аппаратных так и программных.

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

Все это очень смущает. Почему тогда у вас не слетал Flash? Помеха была такой умной, что генерила только команду записи eeprom? Звучит абсурдно.
И не проще ли отключить reset в таком случае? Для восьминогой Tiny13 дополнительная ножка куда более актуальна чем вкл/откл ISP.

Кстати, уважаемый defunct, вот нашел в этом же форуме тему, связаную со стиранием памяти контроллера в результате влияния помех на SPI - - -
http://electronix.ru/forum/index.php?showtopic=47174

[defunct]

На сколько я понимаю, даный форум был создан для того, чтобы люди смогли получить ответы на свои вопросы и поделиться опытом, а не слышать в свою сторону "несешь чушь"... Хотя Вы, уважаемый defunct и "Гуру", но с вашей стороны это мягко говоря неуважение к нам форумчанам.

это просто метки которые форум сам расставляет от количества постов. Никакого отношения к квалификации эти метки не имеют. Я бы был непротив если бы вместо "гуру" у меня там было написано "кекс".

Ну включили вы свой БОД, ну есть цитата в даташите:
...
Да в этом Вы правы, но, судя из моего опыта - это не всегда срабатывает...

Хорошая попытка...

В моем случае порча ЕЕПРОМ часто происходила в тех же случаях, что и у Kalina, и у Len_OK, создавшего эту тему, а именно в момент присутствия каких либо напряжений на Vcc и линиях SPI, при этом на Reset было 0В.

А у меня порчи eeprom от этого не происходило. Что я делаю не так?

И во-первых: !!!Внимательно!!! читая данную тему я заметил, что Kalina работал с Мега8, а там вообще нету debugWire...

"Внимательно" читая данную тему Вы бы заметили, что тема называется "Tiny13". Какое отношение к этой теме могут иметь способы применимые на mega8? В m8 можно разместить бутлоадер и с легкостью перешивать чип через любой доступный интефейс. С t13 такой фокус не пройдет, но есть debugWire.
Я как раз стараюсь быть в русле темы не переключаться на другие чипы.

Во-вторых:на сколько я знаю для debugWire надобно заиметь не совсем простой программатор...

А разве это не обязательное условие для нормальной работы? Или Вас больше устраивает верить в то что SPI интефейс (которого кстати в Tiny13 нет) каким-то образом может стирать EEPROM?

В-третьих:если Вы отключите Reset, то не сможете программировать по SPI и Вам снова придется заиметь не совсем простой программатор...

Да разумеется, но в свете откровенно станного совета - отключить ISP - отключение Reset'a для Tiny13 смотрится куда более разумным выходом, т.к. хотя бы добавится драгоценный для этого чипа пин.

В-четвертых:может быть Вы посоветуете еще и кодировать сами записываемые данные кодами Хеминга, Грея и т. п. Что же у Вас за ключ такой получится???

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

В-пятых:сама компания Атмел гарантирует правильную работу при соблюдении всех правил использования ЕЕПРОМ, как аппаратных так и программных.

Мы не застрахованы от пропадания питания и/или подачи сигнала Reset во время записи ячейки EEPROM, следовательно никаких гарантий нет и быть не может. Гарантии достигаются дублированием важной информации.

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

Разумеется я вам и не указ. И мне все равно как те или иные задачи будут решены.
Я просто высказываю свое мнение, а оно у меня таково - взаимосвязи между стиранием EEPROM и отключением ISP нет.

вот нашел в этом же форуме тему, связаную со стиранием памяти контроллера в результате влияния помех на SPI

Я ее читал - там нет ни одного серьезного факта подтверждающего стирание памяти. Только "друг сказал", "где-то слышал", "кто-то жаловался" и т.п, это можно расценивать как реальные факты?.

[Kalina]

Или Вас больше устраивает верить в то что SPI интефейс (которого кстати в Tiny13 нет) каким-то образом может стирать EEPROM?

Интересненько, а как же без SPI этот контроллер вообще можна прошить? Может вам удавалась его прошить по debugWire?