Контроллер AtMega64, запаянный в плате. При программировании устанавливаю Fuse - SPIEN, BOOTRST, частоту. Сначала все читается, заливаю прошивку, заливается нормально, контрольное чтение проходит правильно, после этого доступа к микросхеме нет. Совсем нет. Сообщает об ошибке ISP Mode Error. Контроллер AtMega64 на 8 МГц, корпус TQFP, программатор AVR Dragon, программирование по ISP. В чем причина и-главное - можно ли как-то вернуть микросхему к жизни? Контроллер работает при этом, все порты функционируют, то есть, программа выполняется. Может ли быть (теоретически) причина в прошивке? Хотя та же самая прошивка на другом устройстве к такому эффекту не приводит. Может ли быть причина в плате - разводке, соединении выводов? На этих же выводах сидит RXD, TXD (но выключены).

Попробуйте перед программировнием считать состояние фюзов с новой микросхемы и не трогать SPIEN.
Проанализируйте увиденное.
Ещё возможно, какой-то конфликт с rs-232, сигнал с которого приходит на те же выводы, что и программатор. Он может быть отключён, но MAX232 об этом не знает...
Снизьте скорость работы программатора.

А что изменится? В том контроллере, который не программируется, программатор при подключении пытается считывать сразу.
Снизьте скорость работы программатора.

Снижал до самого минимума. Бестолку.
MAX485 как может влиять? Я пробовал и на вход выходы ставить, и на выход - одинаково.

У MAX485 есть вход для передачи и выход для приема, который как раз и может искажать данные от программатора.

Есть, конечно и теоретически может, что и происходит при одновременном обращении по RS-485. Но вряд л и причина в этом, потому что на другой плате с такой же схемой и прошивкой все работает, а здесб даже цифровая подпись контроллера не читается.


Есть, конечно и теоретически может, что и происходит при одновременном обращении по RS-485. Но вряд л и причина в этом, потому что на другой плате с такой же схемой и прошивкой все работает, а здесб даже цифровая подпись контроллера не читается.

Вы похоже не понимаете... Создайте сотню устройств и проверьте, сколько в отказе а сколько работает "с такой же схемой". Я думаю статистика откроет Вам глаза.

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

Покажите схему, или часть - цепи, которые непосредственно подключены к разьему ISP

Это только в понедельник теперь, на работе.

Добрый вечер, я сталкивался с подобной проблемой, решил ее следующим образом: В линию RXD0 и TXD0 совмещенную с линиями програмирования поставил по резистору в 1 кОм, линии програмирования подключил на стороне идущей к МК, соответственно выводы мах232 с другой стороны.

Все очевидные причины - типа мешания микросхемы MAX485. уже проверил - у микросхемы просто ножки отпаял. Ничего не помогает, причина в чем-то другом.

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

Вероятнее всего бит SPIEN установился неверно в результате какого-то сбоя при передаче данных (не исключено также что Вы его по ошибке - простите, но все мы люди - все ошибаемся - установили не так как надо). Результат - не может перейти в режим последовательного программирования, о чем и сообщает. Исправляется параллельным программатором.

Я при программировании данный бит обычно не трогаю - считываю конфигурацию фьюзов которая в МК текущая, исправляю что надо, а потом лью обратно...

Этот бит нельзя изменить по ISP, только через JTAG

Да, действительно... с другой стороны мог еще какой-нить слететь... типа запрет резета или в этом духе...

Мне не понравилось в Replacing ATmega103 by ATmega128 вот эта фраза.

Цитата

4. SPM and Self-programming is not available in ATmega103
compatibility mode. The default factory setting of BOTTSZ1:0 is OK.

А так как Вы этот fuse не трогали , то 64 у Вас работает как 103 Возможно тут собака и порылась.

Этот fuse повлиял бы на работу BootLoader'a, когда же ТС говорит про программирование по ISP на работу которого М103С не оказывает никакого влияния.

Так он работает в режиме MEGA103 , а не в 64 . Про 64 пока можно забыть. У меня нет DS 103-ей что бы посмотреть , нет ли в ней особенностей при программировании по ISP. Она с завода идёт в 103 режиме.

У меня и живая есть. Особенностей у 103-ей нет, мега как мега.

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

+1

Бит SPIEN установлен аппаратно и программатором его снять невозможно.
бит совместимости с 103 отключен, если бы он был включен, контроллер бы работал по-другому, это пройдено уже на этой программе, программа выполняется правильно, значит, бит выключен.
Часть схемы сделал, выложить пока не получается, так как форум профит ссылку с gif, а у меня архив делает все ссылки view.pic. Выложу схему обязательно.
Три платы вот таких одинаковых, однократно запрограммировались. :-D
замена контроллера, конечно, выход и будет сделана, но надо выяснить причину, иначе может то же самое повториться.

Кажется, разобрался. Отрезаю вывод 2 (PE0) от MAX481 и все начинает программироваться. То есть, мешает линия RxD от MAX481. Если в тексте программы принудительно в самом начале конфигурирую порт "DDRE = (0 << DDE0); PORTE = (1 << PE0); " то программируется нормально, но нет обмена по UART. :-D Хотя косяк странный, на предыдущих версия работало нормально.

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

Схема разработана вполне обычно, используется USART0, один из двух возможных. Косяк, кстати, вовсе не очевидный, так как на предыдущей версии платф с точно такой же схемотехникой все работало нормально.

Ну как же не очевидный?! К одному лог. входу (МК) подключается два (!) лог. выхода (программатор + драйвер). И если что то у Вас работало до этого - считайте что удача Вам улыбнулась. Хотя, лично у меня, веры в это нет никакой... Ваш взгляд на схемотехнику меня расстраивает.

Я другое имел ввиду. Эти выводы изначально разработчиками контроллера заложены под 2 функции - SPI и порт данных. Как тогда проводить внутрисхемное программирование, если это не работает?! А ведь внутрисхемное программирование с использованием этих выводов предусмотрено и получается, что в таком случает один из UART использовать нельзя.

Вам же предложили простое и надежное решение - отвязать приемник от контроллера резистором. Напомню, Вы утверждали, что :
---
Все очевидные причины - типа мешания микросхемы MAX485. уже проверил - у микросхемы просто ножки отпаял. Ничего не помогает, причина в чем-то другом.
---
А с резистором - это весьма удобно и избавляет от кучи проблем. Что с USART, что с SPI. А то, бывает, из-за дурной ошибки выходы начинают друг друга перетягивать, схема жрет как не в себя...