ich möchte gerne einen Atmega2561 mit AVRDude Programmieren. Ich benutze einen SDK200 kompatiblen Programmer (den von embedit.de). Ich erhalte leider immer den selben Fehler bei der Verifizierung der Daten. Fuses usw. kann ich lesen, scheint prinzipiell zu funktionieren aber ich bekomme bei mehrmaligem auslesen Unterschiedliches heraus. Ich habe die Hardware mehrmals gecheckt und frage mich nun ob es andere mögliche Fehler gibt (zumal das lesen der Fuses usw. funktioniert). Ich verwende folgenden Befehl und habe die neueste WinAVR Version installiert mit AVRDude-GUI: "C:\WinAVR\bin\avrdude.exe" -p atmega2561 -c stk200 -C "C:\WinAVR\bin\avrdude.conf" -P lpt1 -U flash:r:"C:\Dokumente und Einstellungen\Admin\Desktop\displaycheckwrong.hex":i Außerdem anbei noch der Hexcode den ich gerne Flashen würde und das was herauskommt wenn man wieder (zum ersten mal) ausliest.# Könnt Ihr mir helfen?
Hier anbei noch die ursprüngliche hex-file, der Anhang oben ist die nach dem Programmieren ausgelesene.
Ausser du gibst 14 Eur für nen Controller aus und 20 ct für den programmer ? fällt mir dazu nix ein ?! Hast du wenigstens gleich 4 Controller geholt damit du die verfusten gleich ersetzen kannst ?
HEX-File ist nicht gleich HEX-File. Das Intel HEX Format erlaubt es die gleichen Binärdaten in unterschiedlich aussehenden HEX-Dateien abzubilden. Erst wenn du aus den Hex-Files die Binärdateien machst (mit einem hex2bin-Konverter s. Links in der Artikelsammlung bei EPROM), kannst du auf Binärebene Unterschiede suchen. Für mich sehen deine beiden Hex-files gleich aus, sie sind nur anders formatiert.
Jetzt hat die Forensoftware meine Bearbeitung gefressen! Also nochmal: Der Anfang ist OK. Ab 0x0072 treten beim Auslesen Fehler auf. Dass der Anfang OK gelesen wurde kann auch ein Grund sein, dass das Bearbeiten der Fuses klappt. Dort brauchst du keine langen Schreib- und Leseorgien. Herauszufinden was der Grund für die Probleme ist, ist Fummelarbeit, die ich mir nicht machen würde. Ich würde an deiner Stelle, so wie Christian auch meint, eine zuverlässigere ISP Hardware einsetzen.
Möglicherweise ist die ISP-Frequenz zu hoch für die benutzte Kabellänge. (Wenn sie zu hoch für die CPU-Frequenz des AVRs wäre, dann käme gleich nur Schrott raus.) Man kann bei avrdude mit der -i-Option zusätzliche Delays zwischen den Takten einbauen und damit die ISP-Frequenz verringern (natürlich geht dann alles langsamer). Probier einfach mal, ein -i 10 mit in das Kommando aufzunehmen.
einmal flashen dauert im schnitt ca. 70 sekunden (ohne verifizierung), die Taktrate des µC ist 8Mhz extern, ist das normal (ich habe bisher nie eine so extrem lange zeit zum flashen benötigt, allerdings ebenfalls noch nie mit diesem controllertyp und der taktrate gearbeitet)
sowohl mit -1 10 als auch mit -i 100 keine änderung, immer der selbe
fehler
verification error, first mismatch at byte 0x0000
0x0c != 0x00
Die Kabellänge sind die (langen) mitgelieferten 80cm, der programmer ist
brandneu und bidher unbenutzt gewesen, d.h. er hat auch noch nicht
funktioniert. Hat jemand noch eine idee?
ICh habe nun mit dem selben Programmer ein anderes, altes mega16-board beschrieben, und es funktioniert. nun ist die frage, es liegt offensichtlich an meinem atmega2561 board, welches aber bereits vorher erfolgreich geflasht wurde. - kann es zu inkompatiblitäten zwischen dem Chip und dem Programmer kommen? - kann sich ein hardwareproblem so auswirkewn dass fuses editierbar und lesbar sind, flashspeicher aber nicht?
Das "kleine" Testprogramm funktioniert nun auch auf dem mega2561, d.h. es liegt an der codegröße? kann auch die Hex-Datei fehlerhaft sein?
Welche avrdude-Version hast du denn? Ich muss allerdings zugeben, dass ich mit den Billig-Bitwackel- Adaptern noch nicht versucht habe, einen ATmega256x zu programmieren. Kann also auch sein, dass der Code da noch 'nen Bug hat oder die ISP-Befehle im avrdude.conf nicht korrekt sind.
ich habe im Moment AVRDude aus der neuesten WinAVR Version. Das Programmieren genau derselben Softwaregröße hatte komischerweise mit einem anderen (aber baugleichen) stk200 Adapter bereits völlig problemlos funktioniert.
Kurz Kabellänge, dennoch keine Verbesserung, hat jemand noch Ideen?
1/ Sieht man etwas, wenn man AVRDUDE mit -v im Verbosemodus betreibt? D.h. wenn man versucht möglichst viel Infos zur Übertragung mitzubekommen? Du kannst den Umfang (verbosity) durch mehrere -v erhöhen (bis wieviel max. finde ich auf die Schnelle nicht ohne in die Source zu schauen). Ideal wäre es, wenn man irgendwann ein Art Logfile/Ausgabe erhält, in dem steht oder sichtbar ist, was wann übertragen wird. Vielleicht bremsen andere Anwendungen. Zumindest sieht man dann auch die AVRDUDE Versionsnummer. 2/ Welche Einstellung hast du an der Parallelschnittstelle? Ich würde EPP einstellen (BIOS?) http://www.tarigon.de/tramp/epp-ecp.html
Also die Biossettungs ändern nichts, ich werde jetzt einmal den verbose mode ausprobieren und die resultate hier posten
Anbei eine Logfile der Übertragung im Verbose Mode von AVRDude. Könnt Ihr mir hierzu etwas sagen?
Andreas Plonka wrote: > Anbei eine Logfile der Übertragung im Verbose Mode von AVRDude. > > Könnt Ihr mir hierzu etwas sagen? Nur, dass der ganze Kram hier die Synchronisation verliert:
1 | bitbang_cmd(): [ 48 00 4A 94 ] [ 0C 48 00 4A ] |
2 | bitbang_cmd(): [ 40 00 4B E7 ] [ 94 40 00 4B ] |
3 | bitbang_cmd(): [ 48 00 4B 04 ] [ E7 48 00 4B ] |
4 | bitbang_cmd(): [ 40 00 4C 0C ] [ 04 40 00 4C ] |
5 | bitbang_cmd(): [ 48 00 4C 94 ] [ 0C 48 00 4C ] |
6 | bitbang_cmd(): [ 40 00 4D E7 ] [ 94 40 00 4D ] |
7 | bitbang_cmd(): [ 48 00 4D 04 ] [ E7 48 00 00 ] |
8 | bitbang_cmd(): [ 40 00 4E 0C ] [ 00 00 00 00 ] |
9 | bitbang_cmd(): [ 48 00 4E 94 ] [ 00 00 00 00 ] |
10 | bitbang_cmd(): [ 40 00 4F E7 ] [ 00 00 00 00 ] |
11 | bitbang_cmd(): [ 48 00 4F 04 ] [ 00 00 00 00 ] |
12 | bitbang_cmd(): [ 40 00 50 0C ] [ 00 00 00 00 ] |
Ab dieser Stelle ist vom AVR nichts mehr zu hören oder zu lesen, der scheint den programming mode verlassen zu haben.
Hier das Logfile ohne die 0x00 und auf das wesentliche gekürzt. AVRDUDE klappert die richtige Datei stur bis zum Ende. Ab einer gewissen Stelle (Markierung mit Fehler) antwortet der Atmega2561 nicht mehr korrekt. Im Moment bin ich auch noch nicht schlauer.
hat jemand vielleicht erfahrungen mit dem verhalten? kann es sein dass der µC nicht robust genug im resetb gehalten wird oder ähnliches?
wenn ich avrdude extrem verlangsame (-i 10000 usw.) kann ich nicht einmal die device-id auslesen, d.h. ich glaube dass der fehler etwas mit der zeit zu tun hat die nach dem initialisieren vergeht. könnt Ihr mir sagen was da genau passiert und wie ich darauf einfluss nehmen kann? Danke schonmal. Andreas
Ich bin nun endlich mal dazu gekommen, meinen alten Bitwackel-Adapter aus der Kiste zu kramen und an einen ATmega2561 zu klemmen. Das ist Typ "alf" im avrdude.conf, einen STK200 selbst habe ich nicht, aber viel mehr als die Pinbelegung ist ja bei diesen Dingern nicht anders. Geht alles einwandfrei, ich habe keine Probleme damit. Was mir aber gerade einfällt und was auch zu deiner Beobachtung mit der Zeit, die vergehen muss passt: Hast du sicher gestellt, dass sonst nichts und niemand in der Zeit versucht, auf den Port zuzugreifen? Das ist ja 'n Windows, da werden die Portzugriffe ohne Treiber direkt mittels INB/OUTB gemacht, da Windows keinen Usermode-Treiber für den Parallelport bietet. Wenn aber natürlich mitten beim Programmieren deines AVRs vielleicht der Windows-Printspooler daherkommt und den Druckerstatus erfragen will, dann hast du verloren. Wenn du mir noch sagst, was das Hexfile tut, kann ich gucken, ob mein ATmega2561 das auch macht. ;-)
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.