Hallo zusammen
Ich habe einen AVR Dragon, mit dem ich die Fuses eines Attiny48
schreiben möchte. Wenn ich im ISP-Modus bin, geht dies ohne Probleme mit
TM F. schrieb:> Hat einer eine Lösung?
debugWIRE ist eine Art Monitor-Programm, welches sich fest in einem
(Masken-)ROM der CPU befindet. Als solches kann es nur auf solche
Ressourcen zugreifen, die die CPU auch sonst benutzen kann.
Ein Ändern der Fuses geht daher im debugWIRE-Modus schlicht nicht.
Der von Atmel dafür vorgesehene Rückweg ist daher:
1.) Im debugWIRE-Modus wird ein Kommando ausgeführt, das zu einem
CPU-Reset führt, bei dem anschließend der /RESET-Pin wieder als
solcher funktioniert (debugWIRE damit vorübergehend abgeschaltet ist).
2.) Damit kann man jetzt wieder ISP mit dem Controller „reden“. Dieses
benutzt man dazu, um die DWEN-Fuse zurückzusetzen.
3.) Bei einem Powercycle werden die Fuses neu eingelesen. Ist jetzt
DWEN nicht gelöscht worden, befindet man sich danach erneut im
debugWIRE-Modus, ansonsten normal im ISP-fähigen Modus.
Prinzipiell sagt aber niemand, dass du im Schritt 2.) wirklich die
DWEN-Fuse rücksetzen musst (Atmel Studio macht es aber meines Wissens
immer, wenn diese Sequenz abgearbeitet wird). Du kannst diesen
temporären ISP-Modus genausogut dafür benutzen, einfach nur eine
neue Firmware in den Flash zu laden oder die Fuses anderweitig zu
manipulieren. Nach einem Powercycle wärst du dann wieder im
debugWIRE-Modus.
AVRDUDE implementiert die obige Sequenz, indem du einfach die
reguläre Kommandozeile aufrufst, die du mit ISP benutzen würdest.
Beim Versuch, ISP zu aktivieren, gibt es einen Fehler, woraufhin es
dann versucht, das oben genannte Kommando abzusetzen und anschließend
die komplette ISP-Aktivierung wiederholt.
Edit: Hmm, genau das versuchst du ja offenbar. Seltsam ist, dass die
ISP-Aktivierung offenbar nicht funktioniert, aber auch keine
debugWIRE-Aktivierung mehr. Ob da eine Wartezeit zu knapp bemessen
ist? Um das zu testen, müsstest du jedoch wohl AVRDUDE mal selbst
compilieren. Was passiert, wenn du das Kommando anschließend nochmal
absetzt?
Jörg W. schrieb:> Was passiert, wenn du das Kommando anschließend nochmal> absetzt?
Es kommt die selbe Fehlermeldung, dass die ISP Aktivierung scheiterte.
Das ist seltensam.
Schaltungsmäßig ist aber alles OK, ordentliche Abblockung des
Controllers, keine Kondensatoren an /RESET, Leitungslänge vom Dragon
zum Controller maximal 15 cm? Hast du einen Widerstand von /RESET
nach Vcc? Wenn ja, wie groß?
Klingt mir eigentlich eher wie ein Problem in diesem Bereich.
Jörg W. schrieb:> Schaltungsmäßig ist aber alles OK, ordentliche Abblockung des> Controllers, keine Kondensatoren an /RESET, Leitungslänge vom Dragon> zum Controller maximal 15 cm? Hast du einen Widerstand von /RESET> nach Vcc? Wenn ja, wie groß?
Ich habe einen Kondensator von 1nF gegen GND an der Reset-Leitung. Dies
sollte jedoch kein Problem sein, da die Flanken laut KO sauber
detektiert werden können. Die Leitungslänge sollte in Ordnung sein. Der
Widerstand an der Reset-Leitung gegen Vcc beträgt 4k7.
Dies ergibt ein Tau von 4.7 us.
Das "normale Programmieren geht ja, darum sollte es aus meiner Sicht
auch mit den Fuses gehen.
TM F. schrieb:> Ich habe einen Kondensator von 1nF gegen GND an der Reset-Leitung.
Völlig tödlich für debugWIRE.
Mach den mal ab.
> Die Leitungslänge sollte in Ordnung sein.
Was heißt „sollte“? Der Dragon ist durchaus berüchtigt für seine
eher schwachbrüstigen Levelshifter. Mehr als 15 cm „Hosenträger“
sind dafür bekannt, dort gern zu Problemen zu führen. Des Drachens
Vorbild JTAGICEmkII ist da deutlich besser, benutzt jedoch
Levelshifter von Maxim, die vermutlich für den Billigdrachen zu teuer
waren.
> Der> Widerstand an der Reset-Leitung gegen Vcc beträgt 4k7.
Gerade noch tolerierbar, kleiner darf er nicht sein.
Inwiefern überhaupt ein Widerstand mit debugWIRE benutzbar ist, ist
von Fall zu Fall verschieden. Ich habe Konfigurationen gesehen,
bei denen 4,7 kΩ oder 10 kΩ das debugWIRE-Verhalten verbessert haben,
aber auch solche, bei denen es nur ohne jegliche Beschaltung an
/RESET überhaupt lief.
> Dies ergibt ein Tau von 4.7 us.
Ja, und mit welcher Datenrate gedachtest du, die Bits über diesen
Pin per debugWIRE hin und her wackeln zu lassen? 50 kHz?
> Das "normale Programmieren geht ja, darum sollte es aus meiner Sicht> auch mit den Fuses gehen.
Mit „normal“ meinst du ISP, oder? Da ist /RESET ja de facto eine
statische Leitung (wird nur ganz am Anfang auf low gezogen), ganz im
Gegensatz zu debugWIRE.
Die Baudrate ist auf 100'000 festgelegt.
Mit Programmieren meine ich im DebugWire-Modus. Drauf laden kann ich,
jedoch nicht debuggen( Suche eine gute Anleitung dazu.).
Das Flachbandkabel ist 20cm lang.
TM F. schrieb:> Die Baudrate ist auf 100'000 festgelegt.
Wo?
Die, die du AVRDUDE mitgibst, interessiert hier überhaupt nicht.
Laut
http://www.ruemohr.org/docs/debugwire.html
ist die debugWIRE-Datenrate clk/128 (by default).
Ich kann dir nur sagen (und ich habe damit im Verlauf der Entwicklung
von AVRDUDE und AVaRICE einiges rumgespielt), dass ich das
Hardware-Setup für debugWIRE stets als verdammt fragil erlebt habe.
Wenn die Hardware läuft, ist es schneller, als ich aufgrund der
„Innereien“ vermuten würde, aber wenn die Hardware spinnt, dann ist
die DWEN-Fuse ein schneller und unkomplizierter Weg, sich ins Knie zu
schießen, da man zwingend ein funktionerendes debugWIRE benötigt, um
den Rückweg zu ISP zu gehen – zumindest mit den Atmel-Tools. (Wenn ich
mir obige Seite mit den REverse-Engineering-Erkenntnissen ansehe,
könnte es auch einen alternativen Rückweg geben, der keine Atmel-Tools
braucht.)
Wenn du denkst, dass dem anders ist, dann würde ich mich an dieser
Stelle verabschieden, da ich dir nicht weiter helfen kann.
Jörg W. schrieb:> Wo?
Im Config-File von AVRDUDE. ( Habe ich nachträglich verändert, damit ich
nicht jdes mal den Parameter -B 10 mitgeben muss)
Als Entwicklungsumgebung benutze ich CodeBlocks.
TM F. schrieb:> Im Config-File von AVRDUDE. ( Habe ich nachträglich verändert, damit ich> nicht jdes mal den Parameter -B 10 mitgeben muss)
Und?
Ich schrieb dir doch, dass das kein Schwein interessiert im dW-Modus.
Warum magst du mir das nicht glauben? Kannst dich ja gern selbst durch
den AVRDUDE-Code wühlen.
Löt' endlich den blöden Kondensator von /RESET ab, wenn du mit
debugWIRE auf einen grünen Zweig kommen willst.
p.s.: Bildformate
Hast du vielleicht doch noch ein kürzeres Kabel übrig?
Im Moment ist mir die komplette Abfolge deiner Ereignisse überhaupt
nicht mehr klar. Da oben steht ein ISP-Kommando, aber ansonsten
schreibst du, dass du mit debugWIRE programmieren kannst, und was
hier wie das Code::Blocks tut, hab' ich keine Ahnung (hab' ich selbst
nie benutzt).
Irgendwie passt das alles nicht ganz zusammen.
Kannst du mal einen kompletten Log schicken von den Kommandos, die
gehen und denen, die nicht gehen? (Aber bitte nicht als Bild, sondern
als Text, am besten als angehängte Datei.)
Dann bräuchte ich vom ersten und dritten mal die Logs mit -vvvv, denn
an sich ist das ein Widerspruch in sich, dass das debugWIRE zum
Programmieren aktivierbar ist (und funktioniert), aber für den
Rückweg zu ISP nicht aktivierbar ist.
Ach, eine AVRDUDE-Version bräuchte ich auch noch dazu.
Habe mir gerade mal einen ATtiny4313 gekrallt (ist der einzige
dW-fähige AVR, den ich hier zur Hand habe), ihn in einen STK500
gesetzt und einen Dragon angehängt. Anbei das Logfile mit -vvvv,
wenn man einmal die DWEN-Fuse hin und her schaltet (hfuse auf 0x5F,
danach Powercycle, danach hfuse wieder auf 0xDF).
Prinzipiell funktioniert die Reihenfolge also durchaus so, wie sie
gedacht ist.
Hier sind die beiden Files.
Das Programmierfile ist nicht komplett, weil ich ein Problem mit dem
herausschreiben des Befehles in ein File habe.
Und vielen Dank für die Mühe, die du dir nimmst, um mir zu helfen :)
TM F. schrieb:> Das Programmierfile ist nicht komplett, weil ich ein Problem mit dem> herausschreiben des Befehles in ein File habe.
Hmm, aber der wesentliche Anfang (Aktivierung von debugWIRE) fehlt. :(
Lenk' doch die Ausgabe in eine Datei um:
Ich korrigiere mich: das Aktivieren des debugWIRE-Modus wird vom
Dragon anstandslos akzeptiert (Parameter 3 auf Wert 0 setzen). Er
akzeptiert auch den anschließenden Reset-Befehl (0x0b) mit dem
Parameter 0x04 ("with debugWIRE disabled").
Danach sollte das Target eigentlich wieder einen normalen /RESET-Pin
haben, mit dem man ISP machen kann. Die nachfolgende
ISP-Initialisierung (Parameter 3 auf Wert 3) jedoch funktioniert bei
deinem Dragon nicht (Antwort 0xA0 => FAILED), anders als bei mir.
Da du oben schriebst, dass sie auch bei einem erneuten Aufruf des
gleichen Kommandos nicht funktioniert, liegt es vermutlich nicht daran,
dass die erneute ISP-Aktivierung zu knapp nach dem RESET kommt,
insofern wird es auch nichts helfen, da eine Totzeit reinzusetzen.
Sehe ich nur zwei Möglichkeiten:
1.) Du kannst Atmel / AVR Studio mit deiner Firmwareversion auf
USB-Ebene tracen, damit man sehen kann, was sie an dieser Stelle
anders machen, und AVRDUDE entsprechend anpasst.
2.) Du bringst deinen Dragon auf eine neuere Firmware in der Hoffnung,
dass diese in dieser Hinsicht dann so funktioniert wie die bei meinem
Dragon. (Dein Problem habe ich allerdings in dieser Form auch mit
früheren Firmwareversionen noch nie gesehen. :~)
TM F. schrieb:> Gibt es eine Möglichkeit, die Dragon Firmware zu updaten, ohne dass man> das Atmel Studio installieren muss?
Leider nicht.
Theoretisch brauchst du natürlich nur das .exe-File fürs Aktualisieren
der Firmware, aber das kommt halt nur im Verbund mit dem Atmel-Krams
daher, und die Firmware selbst auch.
Vielleicht findest du ja jemanden, der ein Atmel Studio hat, bei dem
du den Drachen mal anstöpseln kannst?
Ich hab jetzt Atmel Studio installiert und die Firmware auf den neusten
Stand gebracht. Wenn ich jedoch mit dem Dragon die Fuses programmieren
möchte, kommt folgende Meldung:
TM F. schrieb:> Ist dies zurückzuführen, auf das DWEN-FuseBit, das immer noch gesetzt> ist?
Ja, das könnte sein. Soweit ich mich erinnern kann, rechnet das
Studio nicht mit dieser Situation, da aus seiner Sicht DWEN ja nur
gesetzt sein kann, während es sich selbst in einer Debugsitzung
befindet …
Aber vielleicht geht ja AVRDUDE jetzt mit dieser Firmware?
Jörg W. schrieb:> Aber vielleicht geht ja AVRDUDE jetzt mit dieser Firmware?
Habe ich auch versucht, ändert jedoch nichts.
Ist wohl die einzige Lösung, den aktuellen Attiny48 abzunehmen und einen
neuen drauf zu löten, der das DWEN-Fuse noch nicht gesetzt hat.
TM F. schrieb:> Ist wohl die einzige Lösung, den aktuellen Attiny48 abzunehmen und einen> neuen drauf zu löten, der das DWEN-Fuse noch nicht gesetzt hat.
Sehr seltensam, dass das bei dir nicht funktionieren will.
Einen ATtiny48 habe ich nicht hier, mit einem ATmega48 oder 88 kann
ich es ggf. nochmal versuchen (sollte sich bezüglich dW genauso
verhalten wie die Tinys, meiner Erinnerung nach hat man da vor allem
den Multiplizierer „abgerüstet“, um billigere Chips zu bekommen).
Ich habe den Fehler gefunden:
Das Fuse-bit RSTDISBL habe ich am Anfang auch auf 0 (programmed)
gesetzt, zusätzlich zum DWEN.
Jetzt konnte der AVR Dragon nicht den Controller reseten, wenn er die
Fuse-Bits im DebugWire-Modus nicht schreiben konnte und versucht hat,
den ISP-Modus zu aktivieren.
Ich habe den Attiny48 ausgewechselt, das RSTDISBL auf 1 gelassen und
jetzt funktioniert es.
@ Jörg Wunsch
Danke für deine Hilfe und Mühe
TM F. schrieb:> Das Fuse-bit RSTDISBL habe ich am Anfang auch auf 0 (programmed)> gesetzt, zusätzlich zum DWEN.
OK, das erklärt die Sache natürlich. Schön, dass du dem noch auf die
Schliche gekommen bist! Jetzt ist mein Weltbild wieder in Ordnung. :-)
