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?
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?
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.
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
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.
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. ;-)
