Если я правильно понимаю, о каком ключе идет речь - то оттуда откуда подается питание выбросов быть не должно.


В такой ситуации он портится, только если питание падает в сам процесс записи.

Кстати, содержимое часто перезаписывается? или 1 раз записали, а потом только чтение ?
Если второй вариант - то проще будет код зашить во flash.

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

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


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


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

Если с питанием - всё нормально, то ячейка может не читаться только если в этот момент происходит запись в EУPROM. Записываются данные в EEPROM этой же программой? Или программатором? Если программой, то, может быть после записи перезалить программу, отключив (закоментировав) кусок с записью данных в память, и проверить чтение и слёт памяти.

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

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

Данные пишутся этой же программой, но для произведения записи, должен прийти запрос от ком-порта

Сообщение отредактировал Len_OK - May 13 2008, 11:08

На сколько я понимаю, даный форум был создан для того, чтобы люди смогли получить ответы на свои вопросы и поделиться опытом, а не слышать в свою сторону "несешь чушь"... Хотя Вы, уважаемый 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 и Вам снова придется заиметь не совсем простой программатор...
В-четвертых:может быть Вы посоветуете еще и кодировать сами записываемые данные кодами Хеминга, Грея и т. п. Что же у Вас за ключ такой получится???
В-пятых:сама компания Атмел гарантирует правильную работу при соблюдении всех правил использования ЕЕПРОМ, как аппаратных так и программных.

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



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

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


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


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


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


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


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


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


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


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


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

Уважаемый defunct, во-первых вот вам скриншот из даташита АТтини13.
Во-вторых: http://electronix.ru/forum/index.php?showtopic=47174

Ну и что Вы хотите показать этим скриншотом?
Насчет приведенной ссылки - потрудитесь ее просмотреть, я в ней принимал участие.

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

Ну, может я слепой, но на скриншоте четко видно, что в АТтини13 есть SPI, которого по Вашему утверждению там нету...


Ссылку я просмотрел, извините, что не уточнил, но ее я скинул для уважаемого Len_OK, о котором мы с вами к сожалению забыли...

периферийного устройства "SPI" такого как в m8 в t13 нет.

SPI который используется только для ISP программирования, в нормальном режиме отключен. Надо всего лишь подтянуть Reset к питанию и включить BOD.

T13 можно шить LVSP, HVSP и dW программаторами.
Через dW конечно удавалось его шить иначе было бы очень неудобно отлаживать.

Включите BOD на 4.5v . Если BOD нет - ставьте внешний супервайзер на ресет.