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

Раздел ДШ "Preventing EEPROM Corruption" читали?

по питанию всё нормально, пробовала на корпус давать +5!После этого и начинаются проблемы с чтением и данные изменяются.

Возможно, при включении питания у Вас - кратковременный выброс напряжения питания >6V.

как можно избавится от этого?

Взять хороший блок питания

Какой такой БП, если это электронный ключ ?

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

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

если кратковременный - защитный диод поставить на 5-6В

Питание на него (+5В) откуда-то подаётся...

Легче - подтянуть линии SPI, чем потом пользоваться высоковольтным программатором

А разве бывают диоды с падением 5-6 В
Помоему на диоде обычно падает 0.7 В

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

EEPROM портится, когда питашка падает до уровня слишком низкого для нормальной работы ядра. Не допускайте подобной ситуации, и не будет проблем.
Удачи!

Если я не ошибаюсь, так EEPROM это энергонезависимая память, какая может быть зависимость от напряжения питания? Разве что сам контроллер при понижении питания производит её хаотическую перезапись.

Обычно, flash слетает при превышении питания выше некоторого уровня. Слишком низкое питание - тоже не способствует правильной работе

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


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

Кстати, содержимое часто перезаписывается? или 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.

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

На сколько я понимаю, даный форум был создан для того, чтобы люди смогли получить ответы на свои вопросы и поделиться опытом, а не слышать в свою сторону "несешь чушь"... Хотя Вы, уважаемый 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 нет - ставьте внешний супервайзер на ресет.

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

Что значит "SPI который используется только для ISP программирования, в нормальном режиме отключен"???
Что такое нормальный режим??? (Что, есть еще и ненормальный???)
В каком режиме продается данный МК в магазинах(в нормальном или ненормальном)???
Чем же его прошить первый раз после покупки???

Приведите, пожалуйста, хоть один факт, или документ, который что-то из этого подтверждал... Может у меня мало опыта в работе с АВР...

Может Вы говорите на каком-то другом языке: причем тут периферийное устройство SPI и протокол по которому прошивается память контроллера SPI.
SPI - это, на сколько я знаю, Serial Peripheral Interface. У большинства 8-битных МК фирмы Атмел этот интерфейс используется для загрузки программы в память МК. А у некоторых МК той же фирмы на борту есть еще и встроенный аппаратный SPI интерфейс (периферийное устройство), который исползуется для связи МК с другими устройствами (память, ЖКИ, другой МК,...), и который может работать в режиме Мастер или Слейв, но он не принимает участия в программировании МК без дополнительных программных вмешательств (типа бутлоадера). Вот SPI, как периферийное устройство в тини13 отсутствуей, а SPI как интерфейс программирования там есть (что видно из скриншота)...

Не ругайте сильно, что отвлекся от темы, просто мне не понятно почему в оригинальной документации написано одно, а Ваш опыт говорит о другом.

Интерфейс debugWIRE позволяет выполнять отладку прямо на кристалле, что раннее было доступно на микроконтроллерах более высокого класса. Это позволит инженерам-проектировщикам усилить желание вывести продукцию на рынок за более короткий промежуток времени, т.к. имеется возможность начать выпуск продукции раньше, чем закончится отладка программного обеспечения. Встроенная отладка дает возможность проектировщикам выполнять отладку прямо на готовом устройстве. Именно для этого Atmel внедрила модуль debugWIRE в свои устройства. debugWIRE использует линию сброса для электрического соединения, благодаря чему проектировщики не столкнуться с проблемой потери линий ввода-вывода при использовании системы встроенной отладки. debugWIRE и пользовательский интерфейс AVR Studio ® дают проектировщикам полное управление ресурсами микроконтроллера, помогая уменьшить время проектирования за счет более простого процесса отладки. DebugWIRE позволяет выполнять отладку 8-разрядных микроконтроллеров, которые имеют малое число выводов. Как например 8-выводной. tiny 13 и 20-выводной tiny 2313 не имеют достаточного числа выводов для поддержки JTAG –интерфейса, которому требуется 4 линии ввода-вывода.

Чесно говоря, первый раз слышу про такую возможность шить по dW, если вас не затруднит, не могли бы вы поделиться на конкретном прирмере, в даташите на tiny13 я ничего такого не нашёл. Поиск в гугле dW программатора также дал 0 результат , неужели это засекречено?





При отключении SPI помехи никуда не делись, это понятно. Способность проникновения от этого вряд ли стала меньше. А вот возможность чего-то натворить в МК сразу отпала, проще говоря ей просто закрыли двери!

Значит что в пользовательской программе его использовать нельзя.


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


в отключенном.


Программатором, но вначале так или иначе надо будет куда-то запаять. А уж потом шить.


Да есть, но он отключен когда выполняется программа пользователя.


Ну а что через JTAG можно программировать слышали?
Точно также программу можно зашить и через dW. При отладке AVR-Studio сама заливает программу в чип через dW, т.е. Вам не нужно отключать dW, зашивать программу и включать dW обратно, для того чтобы отладить программу. Единственное ограничение в работе через debugWire - нельзя программировать Fuses и Locks.

Про возможность JTAG программирования я не только слышал, но и читал в даташите на мегу16. А вот про программирование тини13 по dW всего лишь слышал от вас, приведите хоть сылочку что ли...

Ну на счет режимов Вы наконец что-то конкретное сказали, и начали называть все своими именами... (кстати, а почему бы не назвать отключенный режим нормальным)...

ИМХО, так и надо было написать, что в режиме выполнения пользовательской программы SPI, который используется для программирования отключен, сразу всем бы ясно было, ато Вы пишите, что в тини13 его вообще нету.

Я, например, и не всегда впаиваю контроллеры сразу в плату, а пользуюсь панельками программатора (у меня СТК-500).

И еще вопрос, изначально эта тема подразумевала использование МК в "ненормальном" для Вас режиме, тоесть в режиме переходных процессов при вкл/выкл питания, и возможность при этом порчи ЕЕПРОМ (по причине нахождения МК в режиме программирования, или превышения напряжения питания, или помех, и т.д.) так вот, какое отношение к данному вопросу имеют Ваши хваленые dW и JTAG???

Запустите AVR-Studio.
Откройте Help->AVR Tools Users Guide->JTAGICE MKII.
Перейдите в раздел On-Chip Debugger Options
в нем подраздел Debug Dialog -> debugWire.
Там будет скриншот, где видно что для debugWire можно настроить Program Download опции.
цитата:




Естессно никакого, точнее ровно такое же как и рекомендация отключить ISP.

Бороться с переходным процессом надо другим способом - BOD / внешний супервизор питания, подключать пины через низкоомные резисторы вблизи выводов МК, шунтирующие конденсаторы по питанию... Программные средства защиты - дублирование записей в eeprom, код защиты.

OFF
defunct дык поставте себе "кекс" в профиле



Следите за движением буковок ISP != SPI и расшифровываются они совсем по-разному,
а для подтверждения моих слов, идем ВНИМАТЕЛЬНО читать раздел
SPI Serial Programming в даташите на mega128

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

Почему же - "левым"? High-voltage Serial Programming

И куда же этот High-voltage подавать? На ногу, которая была сбросом, а теперь стала портом? Я думаю она просто сгорит нафиг и все.

P.S. А есть программаторы которые шьют в таком режиме?

Вы ДШ прочитайте - там всё написано. Если нога Reset в fuses установлена как PB5, в High-voltage Serial Programming есть определенный алгоритм придать ей функцию Reset'a

Может не будем разводить базар вокзал в ветке форума посвященной сбросу данных в ЕЕПРОМ в обсуждение качеств программатора и назначение пинов

Я тоже касаюсь этого вопроса.
И может ли произойти сбой ЕЕПРОМ при импульсной переполюсовке питания. Амплитуда +5В

Правильное предположение.

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