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

[Len_OK]

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

[Kalina]

либо при чтении обнаруживаются изменённые данные!

Вот с этим я знаком, у меня тоже наблюдалось изменение данных в EEPROM контроллера Mega8.
Проблема заключалась в следующем : в моменты включения - выключения устройства, были подключены линии программирования (SPI), вследсвтии переходных процессов наводились помехи, которые переводили контроллер в режим программирования, результатом служило изменение данных в EEPROM. Проблема была решена, после запрета на режим последовательного программиров. установкой бита SPIEN в 1.

[defunct]

Проблема заключалась в следующем : в моменты включения - выключения устройства, были подключены линии программирования (SPI), вследсвтии переходных процессов наводились помехи, которые переводили контроллер в режим программирования, результатом служило изменение данных в EEPROM. Проблема была решена, после запрета на режим последовательного программиров. установкой бита SPIEN в 1.

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

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

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

в том то и дело, что данные портятся во время чтения, запись обычно производится нормально. И есть ещё такая ситуация, что одна ячейка читается, постоянно, а другая иногда не читается

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

[Kalina]

Да ну бросте городить чушь. BOD надо включать, а не SPIEN смыкать

А почему вы решили, что я говорю чушь? Я сейчас вам всё объясню и вам станет понятно.
1. Изменение данных EEPROM производилась и после того, как я убрал часть кода, отвечающего за её изменение.
2. BOD у меня включен в обязательном порядке на порог 2,7В
3. Случалось это только в моменты коммутации шлейфа программирования при РАБОТАЮЩЕМ контроллере, причём непредсказуемо. В моём случае (на мой взгляд) следующая ситуация : в определённые моменты времени уровень на линии RESЕT достигал низкого уровня, при этом по линиям MOSI, SCK могли проходить помехи которые и преводили МК в режим программирования.
4. После того как я отключил SPI, проблема сналась, это факт!

[Палыч]

...в определённые моменты времени уровень на линии RESЕT достигал низкого уровня, при этом по линиям MOSI, SCK могли проходить помехи которые и преводили МК в режим программирования. После того как я отключил SPI, проблема сналась, это факт!

Хотя теория вероятности и говорит, что существует вероятность того, что помехи могут сложится в соответствующие команды программирования, но, я в данном вопросе я солидарен с defunct. То, что отключение SPI помогло, может быть объяснено и по-другому: например, помеха была довольно мощной и по цепям SPI в МК проникало напряжение >6V, которое губительно для памяти; отключили SPI - помехе стало труднее проникать...