Hallo, ich habe ein sehr seltsames Problem. Vielleicht kann mir jemand einen Denkanstoß geben. Ich habe zwei identische Platinen bestückt mit einem Atmega128. Diesen programmiere ich über einen AVRisp MKII. Als Programmierumgebung nutze ich Atmel Studio in der Version 6.2.1563. Bei der einen Platine erschien beim Programmiervorgang (nach zahlreichen erfolgreichen Programmiervorgängen) irgendwann folgende Fehlermeldung: "ispProgramMem: Error status received: Got 0x80, expected 0x00 (Command timed out) Details: Severity: ERROR ComponentId: 20100 StatusCode: 1 ModuleName: TCF command: Modules:writeToMemory failed." Alle Versuche, den Mikrocontroller neu zu programmieren, schlugen fehl (Fusebits können ausgelesen und geändert werden, Device ID kann ausgelesen werden, Erase funktioniert ohne Probleme): ich habe viele Einstellungen herum probiert. Fuse Bits auf internen Quarz gestellt; das Programm minimiert (endlosschleife, die nichts tut); ISP Geschwindigkeit auf allen erdenklichen Einstellungen getestet; einen anderen Programmieradapter verwendet (anderer AVRisp MKII) und sogar mit Bascom und passendem Bascom Programmieradapter versucht, den uC zu programmieren. Alles vergebens. Daher habe ich die andere Platine ausprobiert. (Minimal-)Programm drauf geladen, alles wunderbar. Dann habe ich das ursprüngliche Programm, bei dem o.g. Fehler auftrat auf den uC geladen. Ich bekam dieselbe Fehlermeldung. Einziger Unterschied: Ich konnte den uC erasen und anschließend neu programmieren mit Minimalprogramm (Endlosschleife, die nichts tut). Sobald ich das "richtige" Programm wieder laden wollte, kommt der gleiche Fehler. Den Quelltext hier zu posten wäre zu viel des Guten, da er bereits aus über 1000 Zeilen Code besteht. Das möchte ich niemanden zumuten Meine Frage ist nun folgende: Hat jemand schonmal ein ähnliches Problem gehabt? Ist es möglich, dass der Quellcode zur Folge hat, dass ein uC nicht mehr ansprechbar ist??? Oder übersehe ich etwas? Warum kann ich einen uC erasen und neu programmieren, den anderen (identisch aufgebauten) jedoch nicht? Ich stehe absolut auf dem Schlauch und wäre über jeden Tip sehr dankbar!
Was für externe Peripherie hängt an dem ATMega? Könnte diese durch ein Programm beispielsweise mehr Strom ziehen, so dass die Vcc in den Keller geht? Oder könnten externe Signale den Programmierzyklus stören?
Sind die ISP-Pins nur zum Programmieren da oder hängt noch andere Hardware dran?
Sind genügend Abblockkondensatoren vorhanden?
Danke für die Anregungen. Ich habe die 5V Versorgung mit einem Oszilloskop angeschaut. Es gibt keine Einbrüche. Abblockkondensatoren sind vorhanden. An dem SCK Pin hing noch was anderes dran. Ich habe die Leiterbahn jedoch nun durchtrennt und es hängt nichts mehr an den Pins. Jedoch keine Änderung. Ich stehe echt auf dem Schlauch. Was jedoch jetzt auf dem SCK Pin festgestellt habe, ist ein unregelmäßiges Signal, was offensichtlich vom uC ausgehen muss, da nichts anderes dran hängt. Beim Programmieren sollte dies jedoch nicht stören, da der uC ja resettet wird, richtig? Jedoch habe ich an diesem Punkt eine weitere allgemeine Frage: Wie sieht das Programmiersignal eigentlich aus? Also ich vermute zuerst geht die resetleitung auf low. Aber was dann? Muss dann gleich die Taktleitung einen Takt aufweisen? Wie sieht der Takt aus? 50% Tastverhältnis? Kurze Pulse? Wie sehen die Timings der einzelnen Signale zueiander aus? Wieviel us nach dem Reset kommt das nächste Signal?
Benutze mal die Goolge Bildersuche. Diese Signale wurden hier schon mehrmals als Grafikdatei gepostet.
Ok, danke. Dann zurück zu dem eigentlichen Problem: Hat noch jemand eine Idee für mich?
Angehängte Dateien:
-
signal.png
5 KB
Hier habe ich mal einen Mitschnitt des "letzten Stücks" auf dem Bus angefügt. Danach kommt nichts mehr auf dem Bus und AVRStudio gibt o.g. Fehlermeldung aus...
Ändert das Programm die interne Taktrate? Wie hoch ist Deine ISP-Frequenz?
Wie kann das Programm die Taktrate ändern? Das Programm ist zu dem Zeitpunkt, wo der Fehler auftritt noch nicht vollständig auf dem uC (der Programmierprozess bricht mit im ersten Post genannter Fehlermeldung ab). Oder wie meinst Du das? Die ISP Frequenz habe ich von wenigen kHz bis in den MHz Bereich getestet. Überall der gleiche Fehler...
Wieso zum Geier ist da so ein Gezappel auf der Resetleitung, das auch noch viel schneller ist als das Spi-Taktsignal? Und dann noch mittendrin?
Standardfehlerquellen: Alle (A)VCC und GND angeschlossen? AREF nicht mit (A)VCC kurzgeschlossen?
Das Gezappel am Reset irritiert mich auch. Konnte bisher die Ursache
nicht finden.
>>AREF nicht mit (A)VCC kurzgeschlossen?
Die beiden sind kurzgeschlossen. Liegt hier der Fehler?
Pullup ist am Reset. 10k
Angehängte Dateien:
-
DS0000.BMP
17 KB
Ich habe mal einen ATmega168 mit einem winzigen Programm bespielt. Sieht wie im angehängten Bild aus (leider ist die Auflösung wirklich so klein). Oben ist SCK und unten RESET zu sehen. Eine Nachfrage habe ich mal: an welche Pins hast du den Programmer eigentlich angeklemmt? Laut meinem Datenblatt zum ATmega128L ist SCK an PB1, PDI (MOSI?) an PE0 und PDO (MISO?) an PE1.
Die von Dir genannte Belegung ist bei mir ebenso. Wie geschrieben, konnte ich den uC ja auch etliche Male erfolgreich programmieren. dann keine Änderung an der HW vorgenommen o.ä., nur eine andere SW aufgespielt und seitdem tritt besagter Fehler auf.
Erase funktioniert ja laut des Eingangsposts. Läuft ein Minimalprogamm problemlos (also Hauptschleife + blinkende LED), nachdem das "Problemprogramm" auf dem Chip aufgespielt war und danach durch einen Erase gelöscht wurde?
bei einer der beiden PLatinen: Ja. Bei der anderen funktioniert Erase, aber keinerlei Programm lässt sich aufspielen.
bd schrieb: > Die beiden sind kurzgeschlossen. Liegt hier der Fehler? Sofern in der Firmware nichts Gegenteiliges konfiguriert wird. Allgemein schließt man dort nur externe Referenzen oder einen 100nF an. VCC oder interne Referenz schaltet dann die Firmware an.
Die Reset Leitung wird während des Programmiervorgangs ständig auf Low gezogen. Da das bei Dir nicht der Fall ist, sehe ich drei Möglichkeiten: a) Eine andere externe Beschaltung ist stärker als der Programmieradapter und zieht sie zeitweise auf High. b) Das Kabel zum Programmieradapter ist defekt (Wackelkontakt) c) Der Programmieradapter ist defekt. Das der Programmieradapter die Leitung absichtlich wieder "los lässt" (so dass sie auf High geht) halte ich bei diesem Timing für ausgeschlossen. So schnell tut er das nicht.
bd schrieb: > bei einer der beiden PLatinen: Ja. Bei der anderen funktioniert > Erase, > aber keinerlei Programm lässt sich aufspielen. Das klingt aber, als würde die Ursache ziemlich sicher an der Platine liegen. Gibt es vielleicht irgend welche zusätzlichen Bauteile auf der Platine, auf der sich der Controller nicht mehr programmieren lässt? Eventuell auch ein/mehrere Bauteil(e) mit anderen elektrischen Werten (größerer/kleinerer Kondensator/Widerstand etc.)? Oder Kabel zum Test von Funktionen, Lötbrücken/Lotreste? Gibt es einen Schaltplan, der gezeigt werden darf?
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.