AtMega2560 - Failed to enter programming mode

Hallo,
ich schlage mich grade mal wieder mit einem AtMega rum.

Ich bekommen folgende Fehlermeldung:

Zitat:

---

Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0xc0, expected 0x00 (Command has failed to execute on the tool)

Unable to enter programming mode. Verify device selection, interface settings, target power, security bit, and connections to the target device.

---

Hatte das Problem hier shconmal jemand?Anhang 32381


Windows 10, Atmel Studio 7. Treiber des AVRISP MKII per Zadig auf LibUSB gestellt.

//Edit: Um sicher zu gehen, dass ich den ISP nicht falsch angeschlossen habe, hab ich hier noch meine Verschaltung:
Anhang 32382

Anhang 32383


Beim Quarz bin ich mir nicht sicher, ob ich den 1M-Widerstand und die Kondensatoren brauche. Ich hab Schaltbilder mit beidem gefunden oder auch wo jeweils entweder die Kondensatoren oder der Wiederstand abgebildet waren.
Aber das sollte erstmal keine Rolle spielen, um überhaupt mal die Device-ID auszulesen oder sehe ich das falsch?


Ich habe eben nochmal die Pins vom ISP-Anschluß zum µC sowohl beim Arduino2560-Board als auch bei meinem µC durchgemessen und keine Unterschiede feststellen können.

Ist das ein neuer uC oder hast du schon Fuses verstellt?
Bei einem neuen uC ist 8Mhz (interner RC-Takt) mit Teiler von 8 eingestellt (Zumindest bei denen die ich verwende). Somit hast du eine Taktfrequenz von 1Mhz. Könnte sein das die ISP Frequenz zu hoch ist (glaube max. 1/4 der Taktffrequenz).

MfG Hannes

Zitat:

---

.. dass ich den ISP nicht falsch angeschlossen habe, hab ich hier noch meine Verschaltung: ..
.. habe eben nochmal die Pins vom ISP-Anschluß zum µC .. und keine Unterschiede feststellen ..

---

Blöde Frage (ziemlich frech), passierte mir (fast) nur die ersten Male: fabrikfrisch ticken die meisten Controller

Zitat:

---

Zitat von Datenblatt 2549P–AVR–10/2012

10.3.1 Default Clock Source
The device is shipped with internal RC oscillator at 8.0MHz and with the fuse CKDIV8 programmed,
resulting in 1.0MHz system clock.

---

mit dem niedrigen Takt, der bei (zu) hoch eingestelltem Programmiertakt zu Verbindungsstörungen führt.

Nachtrag: Sorry, Hannes war schneller.

Ja, das ist n neuer µC. Aber selbst mit der langsamste ISP-Einstellung (über die 125kHz-Falle bin ich in der Vergangenheit schon öfters gestolpert) hab ich das selbe Ergebnis - allerdings dauerts ein paar Millisekunden länger, bis ich die Fehlermeldung bekomme.

Wenn ich im Einstellungsfenster der Fuses wtc. versuche Daten auszulesen vmi µC bekomme ich die Meldung, dass der ISP verdreht sein könnte. Aber wie gesagt, hier habe ich schon alles nachgemessen.
Die Verdrahtung ist wie beim Arduino2560, den ich ohne Probleme per ISP auslesen kann.

Könnte es damit zu tun haben, dass ich bereits einen 16Mhz-Quarz angeschlossen habe?
Ich meine beim letzten Mal hätte ich da auch alles fertig angeschlossen, bevor ich die Fuses gesetzt habe...

- - - Aktualisiert - - -

Auch kann ich den Chip nicht löschen. Da bekomme ich dann folgendes:

Zitat:

---

Timestamp: 2017-01-31 16:33:04.494
Severity: ERROR
ComponentId: 20100
StatusCode: 131103
ModuleName: TCF (TCF command: Device:erase failed.)

Failed to start programming session before chip erase:Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0xc0, expected 0x00 (Command has failed to execute on the tool)

---

Ich muss also irgendwie den Mikrokontroller dazu bewegen, kein 0xc0 mehr auszuspucken.

Die häufigsten Fehler sind:
auf den Programmierpins zu niedrige Lasten zu haben ( bei mir genügte das Gate eines FET über 1kOhm, das es nicht mehr ging ).
Oder die falschen Pins verwendet - Beim 2560 sind das die Pins PDI, PDO, und SCK nicht wie sonst üblich MISO, MOSI und SCK ( siehe Datenblatt Seite 339 ) .

Der Reset Beschaltung muß auch Aufmerksamkeit geschenkt werden und die AVCC und AGND Pins sollten auch mit entsprechenden Spannungen versorgt werden.
Dann sollte eigentlich alles klappen.

Oh - bist du dir bei den Pins sicher?

Ich habe nun schon zum 4. Mal nachgemessen und bei meinem Arduino Mega2560-Board sind Miso und Mosi auch an Miso und Mosi angeschlossen - und darauf habe ich mit meinem AVRISP MKII Zugriff.
Das ist genau so verbunden wie auf meiner Platine.

Anhang 32393

Hier nochmal der Ausschnitt aus meinem Schaltplan. SD-Reader und MicroSD-Reader sind Buchsenleisten und ich habe zum Testen die Erweiterungen entfernt, um auszuschließen, dass die Kartenleser das Aufspielen behindern.
Zu lange Kabel können es auch nicht sein, die Wege vom ISP zum µC sind oben auf dem Bildausschnitt meiner Platine ersichtlich ;)

//Edit: Ich hab grade nochmal in meiner Projektdokumetation nachgesehen und beim letzten Mal habe ich auch MISO und MOSI genutzt. Die Pins PDI und PDO hab ich bisher noch nie genutzt am AtMega2560.

- - - Aktualisiert - - -

Oh, ich glaube, ich habe meinen Fehler gefunden. Ich habe C4 und R7 vertauscht - die Beschriftung auf der Platine war da etwas sehr blöd...
Somit fehlte der Pullup auf Reset.

Ich geh dann mal löten ;)

- - - Aktualisiert - - -

Update: gibt keins.

Leider hat das auch nicht weiter geholfen.
Am µC selbst kann es eigentlich nciht liegen, da ich µCs aus zwei Chargen habe.

Ich bin mir auch nicht sicher - ATMEL schon - siehe Anhang

Kannst Du den die Controller Kennung auslesen ?
Wenn das nicht geht, brauchst Du das proggen gar nicht erst probieren.
Lange Leitungen waren bei mir noch nie ein Problem.

Ich hab deinen Hinweis im Datenblatt natürlich nachgeschalgen. Aber ich habe auch den Direktvergleich gemacht, am funktionierenden Arduino Mega3560-Board. Und da sind eben MISO und MOSI auch genutzt.

Genau, das Auslesen der Device-ID ist schon das Problem bei meinem Board. Und da ich wie gesagt µCs aus zwei Chargen verwendet habe (einen hatte ich vor ca. 1,5 Jahren gekauft und die Charge funktionierte und funktioniert sicher) vermute ich, dass ich eine Fehlcharge der µCs ausschließen kann.

Ich überlege grade, ob ich einen weiteren µC aufm Breadboard aufbaue um nochmal alles zu testen. Denn auf meiner Platine sehe ich da grade keine Chance den Fehler zu finden.


Bzgl. deines Hinweises: Ist es nicht so, dass der µC über verschiedene Wege programmierbar ist?
Zumindest meine ich da vrhin was gelesen zu haben. Jtag, ISP und seriell (wobei letzteres wohl zu deinem Hinweis passen müsste).
Kann aber auch sein, dass ich da grade zwei Kontroller durcheinander würfle.

Könnte es sein das dir dein SD-Reader dreinpfuscht. Der verwendet ja auch MISO und MOSI.

Zitat:

---

Zitat von Cysign

Hier nochmal der Ausschnitt aus meinem Schaltplan. SD-Reader und MicroSD-Reader sind Buchsenleisten und ich habe zum Testen die Erweiterungen entfernt, um auszuschließen, dass die Kartenleser das Aufspielen behindern.
Zu lange Kabel können es auch nicht sein, die Wege vom ISP zum µC sind oben auf dem Bildausschnitt meiner Platine ersichtlich ;)

---

Wie bereits gesagt, habe ich den Kartenleser entfernt, um genau das auszuschließen.

Kannst du mal ein Bild von deiner bestückten Platine zeigen?

Hmmm...ich hab grade nochmal auf ner Lochrasterplatine meinen Mikrokontroller mit Miso und Mosi getestet. Da kann ich problemlos die ID auslesen. Von daher vermute ich, dass irgend eine Lötstelle auf der Zielplatine nicht sauber arbeitet.
Die Pinbelegung ist exakt die selbe ;)

Im Gegensatz zu meiner Platine habe ich gemäß dem Schaltplan des Arduino Mega3560 3x100nF verpasst.
Auf meiner Platine habe ich 100nF und 22uF parallel, was ja eigentlich eine noch stabilere Versorgung gewährleisten sollte.

Auf der Lochrasterplatine habe ich übrigens wie bei der eigentlichen Platine 1MOhm und 2x22pF am Quarz genommen. Allerdings habe ich vergessen an den Kondensatoren die Masse anzuschließen :D
Mal schauen, ob es damit zu tun hat.

Ich hab auch mal provoziert eine zu schnelle Übertragungsrate zu wählen. Aber dann bekomme ich eine andere Fehlermeldung als oben.

//Edit: okay, also mit den beiden 22pF-Caps hats nichts zu tun. Ich such dann mal weiter meine Dummheit ;)

So, nachdem ich die Platine nun nochmal mit einem frischen µC aufgebaut habe und vor jeder Baugruppe verifiziert habe, dass ich den µC auslesen kann (ich hatte gehofft, dass irgend eine kleinere Störung die Kommunikation blockiert) musste ich feststellen, dass wirklich der Mikrokontroller defekt ist.

Jetzt fängt der Spaß an die TWFP100-Steinchen auszulöten und zu ersetzen.
Ich hab grade zum ersten Mal so Kapton-Tape verwendet (das liegt shcon lange im Schrank...) und muss sagen, dass das echt hilft, die Hitze zu bündeln ;)

- - - Aktualisiert - - -

Oh - das ist jetzt schlecht. Der µC auf der neuen Platine ist eben auch gestorben.
Ich hab jetzt nochmal alle möglichen Kontakte durchgemessen, um nen Kurzen auszuschließen.
Da ich nichts geufnden habe, gehts jetzt wohl weiter an meine eigentliche Schaltung.

Oder gibt es FÄlle von plötzlich sterbenden µCs ohne äußere Einwirkung?
Ich hatte auch schonmal Asia-Arduino-Klone, die nach ner Weile ihren Dienst eingestellt haben...
Ich bestell jetzt auf jeden Fall mal ein paar Ersatz-Kontroller aus kontrolliertem Anbau ;)


Außerdem werde ich den Mikrokontroller auf der Lochrasterplatine ein bisschen im Auge behalten. Wenn der überlebt, muss es an meiner Platine liegen. Wenn der auch stirbt, dann ist es der Mikrokontroller an sich.


So langsam glaube ich, dass es eine Induktionsspitze durch eins der beiden Relais sein könnte - mir fälle einfach nicht mehr ein, was noch das Problem sein könnte. Blöderweise habe ich die Schutzdioden an der Relaisspule genau so weit von der Spule entfernt wie den Mikrokontrollerpin.
Ich überlege grade, ob es Sinn machen könnte, einfach noch ne zusätzliche Diode näher am Relais anzubringen.
Mit den AtMega2560 ist das Ausprobieren nur n teurer Spaß...

Zitat:

---

.. Jetzt fängt der Spaß an die TWFP100-Steinchen auszulöten und zu ersetzen ..

---

Na ja, TQFP100 hatte ich noch nie aus-/ein-gelötet, aber TQFP32 (mega8=>mega168=>mega328) oder TQFP44 (mega1284-neu und vermurkster Controller). Dazu habe ich dieses Miniheizgebläse das mehrere Düsen besitzt. Und eben auch welche für die viereckigen Chips *ggg*. Hab auch den Quarz hier getauscht - 16 MHz gegen 20, ebenfalls recht problemlos.

......Bild hier  
......© Reichelt (Link im Bild - klick drauf)

Ich hab so ne ähnliche Station. Allerdings nur runde Düsen. Is aber okay. Ich klebe das Umfeld mit Kapton-Tape ab und nutz die Heißluftstation ohne Vorsatz, das geht auch ganz gut ;)

Aber erstmal muss ich den Fehler finden...

So, nachdem ich nun nochmal die Platine neu aufgebaut habe, hab ich 4 Bauteile weggelassen, bei denen ich vermute, dass sie mit dem Absterben zu tun haben.
Und bisher klappt es.
Zwei der 4 Bauteile sind die Relais, die ich auf Grund der blöd gelegenen Schutzdioden in Verdacht habe...

Das Problem bei den Spulen ist, dass ich diese mit der großen Massefläche auf der Rückseite verbunden habe. Von da aus führen die Dioden dann zurück zur Versorgungsseite des Relais.
Blöderweise hab ich das erst jetzt gesehen, ein dämlicher Fehler beim Layouten.
Würde es denn vermutlich genügen, wenn ich nun eine zweite Diode so nah wie möglich an der Relais-Spule positioniere oder macht das auf Grund der kurzen Strecke zur Massefläche keinen Sinn?
In letzterem Fall müsste ich das Relais wieder ablöten und mit nem Stückchen Klingeldraht die Wegstrecke zur Massefläche vergrößern.

Das wäre zumindest meine Vermutung, woran es liegt.

Als RElais verwende ich ein Tianbo HJR-4102-L 5V und als Diode ne RS1M. Prinzipiell spricht nichts gegen diese Kombi, oder?

Erwähnen möchte ich noch, dass der AtMega bisher nicht beschrieben wurde, also bei einem kurzen High-Pegel beim Einschalten oder beim Zugriff per ISP evtl. eine Pegelspitze entstanden sein müsste. Wäre sowas realistisch?
Ich versuch mir nach wie vor zu erklären, warum meine Mikrokontroller sterben...