Fehlermeldung beim AVR Studio 7

achim S.

Mitglied
16. Jan. 2010
704
13
18
Berlin Biesdorf
Sprachen
  1. ANSI C
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.

Bekomme seit heute diese Fehlermeldung beim AVR studio. Der verwendete Prozessor wird nicht erkannt und die Werte für Ex, Hi, Lo kann ich nicht eingeben. Verwende einen ICE Programmer, dieser wird korrekt erkannt. Der eingestellte Prozessor stimmt auch. Hat jemand eine Idee was sein könnte?
achim
 
Bei "unable to enter programming mode" könnte es an folgendem liegen:

  • Kein Sytemclock bei ISP Programmierung (falsche Fusebits programmiert)
  • Keine korrekte Verbindung beim ISP Kabel, Kabelbruch.
  • Programmierschnittstelle deaktiviert (Reset Disable oder SPI Enable Fuses)
  • Programmierfrequenz zu hoch, bei SPI
  • VCC nicht in Ordnung
  • C mit zu hoher Kapazität an Reset (falls Reset für das Programmierinterface benötigt wird)
  • sonstige Hardware an Programmierschnittstelle angeschlossen nicht i.O.
Dirk :ciao:
 
Hallo Dirk
bei dem Projekt handelt es sich um ein oft benutztes Programm. die Fuseeinstellung ist x- mal getestet und stammt auch von dir. Habe gerade das Programm neu gestartet, das funktionierende Programm neu kompeliert, wenn ich dann Device programming aufgerufen habe erscheint der ICE programmer korrekt mit Nummer, auch der IC wird korrekt angezeigt. Alle Fuse stehen aber auf 0, wenn ich auf read gehe kann nichts gelesen werden. ISP Kabel habe ich überprüft, ICE auch ausgesteckt und wieder angeschlossen,
Programmierschnittstelle deaktiviert (Reset Disable oder SPI Enable Fuses)
Da könnte was sein, vielleicht ausversehen gemacht. Wo kann ich das sehen oder rückgängig machen?
Da die Hardware schon mejhrfach funktioniert hat dürfte auch kein Problem geben. Oder bin zu doof es richtig zu machen
 
wenn ich dann Device programming aufgerufen habe erscheint der ICE programmer korrekt mit Nummer, auch der IC wird korrekt angezeigt.
Der Soll-Controller, oder die tatsächlich zurückgelesene Signatur?
Also wenn Du die Signatur korrekt auslesen lassen kannst... Lockbits?

SPIEN kannst Du mit dem Studio AFAIR über SPI gar nicht disablen. SPIEN und RSTDISBL können nur mit high voltage programming zurückgesetzt werden.

1. Stromversorgung, Takt und Interface prüfen.
2. Signatur auslesen.
3. Fuses und Locks auslesen.
4. Wenn das nicht geht ChipErase und nochmal versuchen.

Welcher Controller, welche Taktquelle? Ggf Takt extern einspeisen bzw den Takt an einem externen Quarz nachmessen.[/QUOTE]
 
Es wird der SollController angegeben. Es kann nichts zurückgelesen werden. Rufe ich den Punkt auf, kommt sofort eine Fehlermeldung. Signatur kann nicht ausgelesen werden.
Verwende den Attiny 841 mit Quarz. Beim einschalten läuft das Programm auf dem Teil. Habe noch ein Programm drauf mit der eine LED blinkt.
Fuses und Locks lassen sich nicht auslesen. Alles zeigt 0x00 an.
 
Verwende den Attiny 841 mit Quarz. Beim einschalten läuft das Programm auf dem Teil. Habe noch ein Programm drauf mit der eine LED blinkt.
Ok, wenn der korrekt blinkt, stimmt zumindest der Takt.
Es kann nichts zurückgelesen werden. Rufe ich den Punkt auf, kommt sofort eine Fehlermeldung. Signatur kann nicht ausgelesen werden.
Nur "unable to entering programming mode"? Kein genauerer Fehler?

Hat der Versuch 'ne Auswirkung auf das blinken?
Wenn Du den Controller blinken läßt, und den Reset-Pin auf Gnd ziehst (ohne Programmer drann, klar), stoppt dann das Blinken? (und geht wieder los, wenn Du den Rest freigibst?)

Aber andere Controller kannst Du auslesen/programmieren?

Hmm… mit dem AVRisp hatte ich mal 'n Treiberproblem, wo auch nicht in den Programming Mode gegangen werden konnte - Workaround war da, 'n älteren Treiber (der glücklicherweise noch auf dem PC war) wiederherzustellen.
Aber Du hast'n ICE...

Ha
 
Es kommt immer nur diese Fehlermeldung. Wenn ich versuche den IC mit ICE zu lesen hört es sofort auf mit blinken. Habe den ICE abgezogen, Spannung wieder an, blinken fängt wieder an, Reset betätigt blinken bleibt aus. Habe ein anderes Modul mit dem 841 probiert das gleiche.
Nach der aktuellen Software habe ich geschaut. Gesternhat der IC ein neues update drauf gespielt von 1.27 auf 1.29. Danach ging wohl nichts mehr.
 
Kann es sein das ich die Ati841 verfust gabe, wie auch immer. Habe gerade ein ganz anderes Modul genommen mit einem Atmega1284p und den konnte ich nach anpassung auslesen, ohne Probleme. ???????
 
Gesternhat der IC ein neues update drauf gespielt von 1.27 auf 1.29. Danach ging wohl nichts mehr.
???

Kann es sein das ich die Ati841 verfust gabe, wie auch immer.
Möglich...
Aber:
Stromversorgung scheint zu stimmen
Takt scheint zu stimmen
Reset geht
bliebe nur SPIEN, aber die kannst Du eigentlich durch SPI-Programming selbst gar nicht disablen.
Meiner Meinung nach warnt Dich das Studio aber immer, wenn Du kritische Sachen wie den Reset oder auch die Taktquelle ändern würdest.

Hmm… debugwire wäre auch noch 'ne Möglichkeit - wenn Du DWEN gesetzt hast, ist SPI-ISP auch nicht möglich. Ob ein Reset das Blink-Programm stoppen würde, weiß ich nicht.
Ich selbst habe dWire nie eingesetzt - vielleicht kann @TommyB was dazu sagen - wie man das prüfen und ggf zurücksetzen kann?
 
Ob ein Reset das Blink-Programm stoppen würde,
Beim debugwire wird das Reset-Bein als Ein-Draht-Bus verwwendet, /Reset muß folglich intern abgeschaltet/abgekoppelt werden. Genau das findet man auch überall dazu.
Die Dokumentation in den Datenblättern ist teilweise ... dürftig.
Beim Tn441/841 steht zB nichts bei den Bein-Overrides dazu, beim Tn2313/4313 hingegen sieht man, daß DWEN sich wi folgt auf das Reset-Bein auswirkt:
  • der Pullup wird aktiviert
  • der Pegel wird auf "0" gezwungen
  • die Datenrichtung wird durch das dWire-Output festgelegt
Das ist quasi dasselbe wired-and, das man vom TWI kennt - Datenrichtung=Ausgang erzwingt durch die dominante "0" 'n tatsächliches low, Datenrichtung=Eingnag schaltet wegen tristate und dem Pullup 'ne rezessive "1", ein rezessives high.

Aber ich sehe nicht, wo der Reset konkret abgeklemmt ist. Im Tn441/841-Datenblatt würde RSTDISBL die Sleep-Einstellung des Beines unterdrücken, Das Bein selbst ist direkt (über die Analoge Verbindung unter Umgehung der Sleep-Schaltung und des Schmitt-Triggers/Synchronizers) mit dem Reset-Teil verbunden (AIOxn). Das dwire taucht hier wie gesagt gar nicht auf.
Im Tn2313-Datenblatt hingegen sind zwar die Overrides drin, aber hier ist keine Verbindung zum Reset-Circuit zu finden (beim AIOxn steht nichts), das dwire scheint hier zwischen Schmitt-Trigger und Synchronizer abgezweigt auf dem dW-Circuit zu landen (DIxn).

Ok, dWire hebelt also den Reset aus. Klar.
dWire erlaubt außerdem BREAK-Instruktionen im Code (SW-Breakpoints) - das Programm stoppt dann, das dWire-Interface kann dann mit Programmer/IDE kommunizieren.
Auch klar.

Aber kann auch die IDE/der Programmer ein Break erzwingen?
Muß ja irgendwie so sein, sonst könnte man ja via dW nicht flashen (ohne Breaks).

Zurück zum Thema:
DWEN tastet die SPI-ISP-Beine nicht an, sofern da also nichts anderes im Programm eingestellt ist/wird, ist MISO tristate.
Beim konventionellen SPI-Programming aktiviert der /Reset das Interface, der Controller ist Slave, MISO wird zum Ausgang.
Man sollte also eigentlich zwei LEDs (mit geeigneten Vorwiderständen) nach Vcc und Gnd an MISO hängen können - sobald man den Reset auf Gnd zieht, müßte eine LED leuchten. Läßt man den Programmer mit dem Controller kommunizieren (irgendwas auslesen etc) , sollten beide LEDs ... flimmern.

Ist das dWire hingegen aktiviert, sollte nur das Programm einen Einfluß auf die LEDs haben.
 
Zuletzt bearbeitet:
Nach längeren probieren hatte ich die Schnauze voll und habe einen total Schnitt gemacht, alter Prozessor weg und neuen drauf (Platine hat es gerade so überlebt). Wollte das alte Programm mit den Einstellungen von AVR Studio testen, das gleiche wieder. Mit einem ganz anderen Programm daten ausgelesen und (siehe da) es funktioniert. Darauf hin alle alten Programme und Einstellungen gelöscht, ohne Ausnahme. Jetzt scheint alles wieder zu gehen.
Gelernt aus der Geschichte, verändere nie ein Programm was funktioniert.
Wieder was gelernt.

Danke für eure Hilfe
 
Was'n das für'n Package gewesen SOIC14? Und Du hast den runtergelötet? Hast Du den noch? Sind die Beine sauber?
Falls Du mal zu einem Forentreffen kommst (wenn mal wieder eins stattfindet), könnte sich das vielleicht mal wer ansehen (mich würd's grundsätzlich interessieren, aber Basel ist hier nicht grad um die Ecke...)

P.S.: Hattest Du bei dem Projekt vorher mal wegen dWire nachgesehen? Also insbesondere auch, ob Du es da deaktivieren kannst? (Hauptmenu->debug->disable debug Wire)
In #4 meinte ich eigentlich die Signatur lesen lassen ohne daß vorher irgendwas geladen wurde - direkt in's Device Programming.
 
Den Ati gibt es doch nur als SOIC14. Habe viel Praxis beim löten. Man kann es mit Heissluft machen oder mit einem Skalpell, zur Not geht auch Seitenschneider. Habe einige Zeit alten Prozessoren mit ca. 80 Beinen abgelötet, sauber gemacht und neu aufgelötet. Der alte IC ist zerstört und entsorgt. Ablauf: Pins mit einem kleinen feinen Seitenschneider am IC abschneiden, jedes Bein einzeln ablöten, Platine reinigen, IC neu auflöten. Kann kaum was passieren solange die Leiterzüge auf der Platine halten. Danach Pins getestet und es funktioniert alles.
P.S.: Hattest Du bei dem Projekt vorher mal wegen dWire nachgesehen? Also insbesondere auch, ob Du es da deaktivieren kannst? (Hauptmenu->debug->disable debug Wire)
hab ich nicht gemacht, hatte einem anderen Artikel vertraut und dann beim setzen einiger Einstellungen nicht aufgepasst, meine Dummheit.
Basel verändert sich im nächsten Monat nach Berlin. Die Schweiz kann ich mir als armer Rentner nicht leisten
achim
 
Den Ati gibt es doch nur als SOIC14
… oder als MLF oder als VQFN.
Die letzten beiden lassen sich nur mit erheblichem Aufwand entlöten, zumindest wenn's garantiert zerstörungsfrei sein soll.
Beim SOIC verwende ich die Draht-Methode (wobei ich ggf 'ne Kapton-Folie dazwischenschiebe).
 
Hi,

Beim SOIC verwende ich die Draht-Methode (wobei ich ggf 'ne Kapton-Folie dazwischenschiebe).
der Draht in dem Video ist aber verdammt dick :oops:

Früher (so vor 20 oder mehr Jahren), in der Anfangszeit von Hobby-SMD-Lötereien gab es bei einigen Versendern sehr dünne Edelstahldrähte oder Edelstahlfolien auf Rolle. Die gehen recht gut ohne die Beine allzu stark zu verbiegen. Den Draht habe ich mir damals leider nicht besorgt. Die Folie hab ich aber selber in Verwendung. Geht recht gut.

Gruß
Dino
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)