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

[Len_OK]

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

[Палыч]

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

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

[Len_OK]

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

[Палыч]

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

[Len_OK]

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

[Палыч]

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

[Клим]

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

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

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

[Kalina]

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

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

[Vanizma]

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

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

[Палыч]

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

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

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

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

[Serega Doc]

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

[Kalina]

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

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

[sseett]

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

[Kalina]

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

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

[Палыч]

...какая может быть зависимость от напряжения питания?

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

[Клим]

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

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

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

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

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

[Len_OK]

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

[defunct]

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

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

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

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

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

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

[Палыч]

одна ячейка читается, постоянно, а другая иногда не читается

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

[Kalina]

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

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

[defunct]

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

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

[Len_OK]

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

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

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

[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

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

[mart-13]

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

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

Эскизы прикрепленных изображений

 

[defunct]

во-первых вот вам скриншот из даташита АТтини13.

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

[Kalina]

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

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

[mart-13]

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

Ну и что Вы хотите показать этим скриншотом?

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

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

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

[defunct]

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

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

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

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

[ZyBEX]

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

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

[Палыч]

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

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

[mart-13]

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

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

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

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

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

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

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

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

[Kalina]

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

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

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

отключили SPI - помехе стало труднее проникать...

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

[defunct]

Что значит "SPI который используется только для ISP программирования, в нормальном режиме отключен"???

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

Что такое нормальный режим??? (Что, есть еще и ненормальный???)

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

В каком режиме продается данный МК в магазинах(в нормальном или ненормальном)???

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

Чем же его прошить первый раз после покупки???

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

а SPI как интерфейс программирования там есть (что видно из скриншота)...

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

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

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

[Kalina]

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

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

[mart-13]

Значит что в пользовательской программе его использовать нельзя.
Когда выполняется пользовательская программа.
Есть и другие режимы работы МК - сброшенное, отключенное состояние, режим программирования...
в отключенном.
Программатором, но вначале так или иначе надо будет куда-то запаять. А уж потом шить.
Да есть, но он отключен когда выполняется программа пользователя.
Ну а что через JTAG можно программировать слышали?
Точно также программу можно зашить и через dW. Единственное ограничение - нельзя программировать Fuses и Locks.

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

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

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

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

[defunct]

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

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

The Debug Dialog Box when using debugWIRE is shown below.
...
The Program Download section allows different settings for how often the target device should be reprogrammed.

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

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

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

[singlskv]

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

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

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

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

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

[777777]

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

[Палыч]

есть ли возможность после этого перешить его хоть каким-нибудь "левым" способом?

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

[777777]

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

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

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

[Палыч]

И куда же этот High-voltage подавать?

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

[Serega Doc]

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

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

[sseett]

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

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

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

Сообщение отредактировал sseett - May 16 2008, 09:08