Hallo, ich habe folgendes Problem: Wenn ich mittels AVRStudio6 und dem AVRISPMK2 eine Hex Datei auf meinen ATXmega128A1U per PDI übertrage bekomme ich immer folgenden Fehler: "Verifying Flash...Failed! address=0x0200 expected=0xcf actual=0xff" Nun habe ich mir gedacht, dass der Flash Speicher wohl defekt ist und habe sogleich den zweiten ATXMega128A1U auf dem Board mit dem gleichen Programm programmiert und prompt den gleichen Fehler erhalten. Das nun beide Speicher der µCs defekt sind, halte ich für eher unwahrscheinlich. Dazu kommt, dass wenn ich das Programm verändere, sprich z.B. kürze, dann ändert sich der Fehler auch. Z.B. steht dann da: "Verifying Flash...Failed! address=0x0400 expected=0x10 actual=0xff" Zu guter Letzt ist noch erwähnenswert, dass die Programme zum Teil noch funktionieren. Irgendwelche Ideen, wie ich diesen Fehler beseitigen könnte? Vielen Dank Lepo
Kannst Du mal ein Foto von Deinem Aufbau Posten. Normalerweise wenn diese Verifizierungsfehler kommen ist irgendwas mit der Verkabelung faul. Also die Kabel zwar richtig angeschlossen, aber die Kabelfuehrung schlecht. Irgendwie fangen sich die Leitungen vom Programmer zum uC irgendwas ein was nicht zur Uebertragung gehoert.
Angehängte Dateien:
-
Ausschnitt_Board.PNG
56 KB -
Ausschnitt_Plan.PNG
12 KB
Dietrich L. schrieb: > Ist der ISP-Clock zu hoch? Die ATxmegas unterstützen gar kein ISP. Nur PDI. Schaltplan, sowie Board Ausschnitt sind dabei. Den Kondensator an der Clock Leitung habe ich natürlich nicht eingebaut. Vielen Dank Lepo
Waya waya, ich haette bei so einer Leitungsfuehrung um den Quarz herum dolle Bauchschmerzen. Die Datenblaetter sagen zwar man soll den Quarz so nah wie moeglich an den uC plazieren, das heisst aber nicht das er so nah sein soll, dass die anderen Leitungen seinen Takt einfangen.
Das stimmt schon, nur war der Platz wirklich knapp. Außerdem liegt der Quarz, wenn er dann erstmal verbaut ist, 3mm über der Platine statt direkt dadrauf. Dazu ist auch noch Lötstop vorhanden. Und aktuell arbeite ich sowieso noch mit dem internen Oszillator und der externe ist noch nicht einmal verbaut. Lepo
Das kann ja sein, es geht aber nicht nur um den Quarz, sondern auch die anderen Leitungen drumherum die lustig eigene Kapazitaeten und Induktivitaeten formen.
Ich verwende die XMegas nicht, somit kann ich nicht sagen wie das mit den Frequenzen bei der Programmierung ist. Aber wenn Du dieses PCB verwenden willst wirst Du die Programmiergeschwindigkeit so anpassen muessen das die Schlangenlinien durch den Konnektor und am Quarz vorbei keinen Einfluss auf die gesendeten Daten haben.
Wie gesagt Quarz ist noch nicht verbaut. Und die anderen Leitungen sind auch erstmal unwichtig. Die Frage ist für mich jetzt in erster Linie, warum die Verifizierung des Flash fehlschlägt. An mangelhafter Leitungsführung liegt das ja sicher nicht, denn sonst müsste ich ja bei beiden Controllern verschiedene Fehler an verschiedenen Adressen erwarten, was aber nicht der Fall ist, da der Fehler wahrscheinlich nicht reproduktiv wäre. Und nochwas zu PDI. Bei PDI beträgt der Programmiertakt einheitlich 1 mHz und ist nicht verstellbar. Im Gegensatz zu ISP besitzt PDI dann noch die Möglichkeit zu debuggen. Trotzdem bis jetzt vielen Dank Lepo
So, um jetzt alle Kritiker zu beruhigen. Ich habe mit einem Oszilloskop das Signal einmal an den Controller Pins und am Konnektor parallel anzeigen lassen und dann einmal programmiert. Das Signal sieht am Controller einwandfrei aus und zeigt keine Form von negativen Veränderungen. Daran sollte es jetzt also nicht mehr liegen. Lepo
Schon mal geprüft ob du den richtigen Controller in der Software eingestellt hast? das passiert mir recht häufig...
Leon P. schrieb: > Bei PDI beträgt der Programmiertakt einheitlich 1 > mHz Das glaube ich nicht, dann wärst du ja übermorgen noch nicht mit dem Programmieren fertig. ;-) (1 mHz ist halt was anderes als 1 MHz.) In der Tat sieht das aber seltsam aus, dass er offenbar ab der zweiten Page nicht mehr programmieren kann. Da deine Konstellation vollständig von Atmel unterstützt sein müsste, solltest du dich mal an deren Support wenden.
Vielen Dank für die Antworten. Ja mHz und MHz, macht schon Sinn. ;) Den Controller habe ich aber richtig eingestellt. Ich werde mich dann mal an den Support wenden. Danke
Hallo Leon, habe das gleiche Problem mit einem atxmega128a1u in Atmel Studio 6, allerdings über JTAG (AVR Dragon). Unter AVR Studio 5 gibt es das Problem nicht. Das Programm läuft trotzdem, habe lediglich den Verify-Haken entfernt. Scheint also ein Bug von Atmel Studio 6 zu sein. Gruß Sebastian
Ja einen Erase mache ich vorher. AVRStudio5 habe ich noch nicht probiert, werde ich aber gleich mal machen. Scheint ja vielversprechend zu sein. Wenn ich dann eine Antwort vom Support bekomme, werde ich sie hier nochmal reinstellen. Lepo
Leon P. schrieb: > ich habe folgendes Problem: Wenn ich mittels AVRStudio6 und dem > AVRISPMK2 eine Hex Datei auf meinen ATXmega128A1U per PDI übertrage > bekomme ich immer folgenden Fehler: "Verifying Flash...Failed! > address=0x0200 expected=0xcf actual=0xff" Den Effekt kenne ich seit einigen Wochen auch, allerdings bei Mega1284P und Programmierung via ISP. Wie haben 40 Boards damit fertigen lassen und alle einmal geflasht. Das funktionierte noch problemlos. Wegen eines Bugs in der Software mußten dann aber alle noch einmal geflasht werden. Aber bumms: drei davon ließen sich nicht mehr flashen, der Vorgang stieg wie bei dir mit Verifikationsfehler aus, interessanterweise bei allen drei betroffenen Boards an der exakt gleichen Adresse. Und das war ziemlich verdächtig, weil damit zufällige Fehler beim Flashen selber extrem unwahrscheinlich werden. Nachforschungen haben folgendes gezeigt: Der gemeldete Fehler ist nur der erste von vielen. Es ist die Adresse des ersten Bytes, das in der neuen Programmversion irgendwo ein Nullbit hat, wo in der ursprünglichen eine Eins ist. Nachtigall, ick hör dir trappsen... Also testweise mal ChipErase und dann Flash ausgelesen. Wie schon fast sicher erwartet: Trotz positiver Rückmeldung von ChipErase war der Flash nicht gelöscht! Der gelesene Inhalt entspricht exakt einer bitweisen UND-Verknüpfung der beiden Programmversionen. Weitere Nachforschungen haben dann gezeigt, daß bei allen drei Fehlerexemplaren auch das EEPROM betroffen ist. Selber Effekt, kann nicht mehr gelöscht werden, Inhalt entspricht einer UND-Verknüpfung der geschriebenen Daten. Da ist wohl die Löschspannungserzeugung ausgefallen, die offenbar für Flash und EEPROM gleichermaßen verwendet wird. Und bei drei von 40 (also satten 7,5%) kann man wohl auch kaum noch von einem zufälligen Ausfall sprechen, das ist ein Serienfehler. Wir sind gerade dabei, über den Bestücker die Herkunft der Chips zu ermitteln. Ich bin ziemlich gespannt, was dabei rauskommt... > Zu guter Letzt ist noch erwähnenswert, dass die Programme zum Teil noch > funktionieren. Ja, das ist bei unseren Problemkindern auch so. Zufällig hatte sich für beide Programmversionen eine identische Länge ergeben, d.h. die Unterschiede zwischen beiden Versionen beschränken sich auf eine ziemlich kleine Insel, umgeben von einem großen Meer an identischem Code. Sprich: alles, was nicht die geänderte Funktion benutzt, funktioniert noch.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.