Hi Leute, ich verwende nun schon seit einiger zeit den AVR Dragon zum Debuggen eines/mehrerer ATmega88p (debugWire). - AVR Studio - STK500 div. andere Plattformen Leider "stürzt" der Dragon bzw. die Degubbsession permanent ab. ( Disconnect .... ) Ich habe Eindruck dies ist Controllerabhängig. Bei manchen funktioniert das Debuggen Problemlos, bei anderen diese sporadischen Disconnects! Hat jemand ähnliche Probleme? Wenn ja wie bekommt ich diese in den Griff? P.S. Spannung ist i.O., Stecker ist korrekt aufgesteckt, Dragon wurde upgedatet. Danke vorab cb
Wie sieht es mit der Kabellänge aus? (Sollte nicht zu lang sein!) Ist der Pullup Widerstand am Reset auch so, wie Atmel ihn spezifiziert? Sind auch alle benötigten Leitungen VCC, GND, Reset verbunden? Hängt die Schaltung (Zielhardware) an einem Labornetzteil, das seinen GND nicht mit der Erdung gekoppelt hat? (Sowas kann u.U. zu einer Erdschleife und damit zu Fehlfunktionen führen. Hängt der Dragon an einem Labornetzteil? Wenn ja, dann achte tunlichst darauf, dass die GNDs (Dragon und Zielhardware) verbunden sind, bevor die anderen Leitungen verbunden werden. Besonders der Reset! Ich hab es schon erlebt, dass wenn man das nicht macht, man sich den Controller abschießt, da es zu Potetialdifferenzen zw. Notebook und Schaltung kommen kann (teilweise bis zu 60V). Und wer macht schon einen ESD oder Überspannungsschutz an den Debug-Port? (Das macht besoinders viel Freude, wenn man einen Controller im QFN Gehäuse einsetzt) Sonst fällt mir grad dazu nix ein.
Ich weiß es ist lange her und ich habe mich anderswo schon dazu ausgelassen aber: Habe das gleiche Problem. Bei 8MHz internem RC verabschiedet sich die Debug Sitzung direkt oder sporadisch bis immer nach wenigen Einzelschritten. Nach langer Suche habe ich herausgefunden, was die Situation DRAMATISCH verbessert. Der Dragon kommt beim Lesen großer Speicherbereiche durcheinander. Daher sind bei Einzelschrittausführung folgende Fenster zu schließen: - Speicher - Dissassembler Damit läuft der Debugger jetzt schon seit einer Stunde im AutoRun ohne Abbrüche! Die oben genannten Fenster können wohl geöffnet werden, müssen aber vor dem nächsten Schritt wieder geschlossen werden. Das ist nicht schön aber damit lässt sich besser leben als nicht debuggen zu können...
Klingt interssant. Werde mir das bei Gelegenheit mal ansehen... Ich hab diesbezüglich auch mal mit nem FAE von Atmel telefoniert und der hat mir gesagt, dass dieses Problem insbesondere bei schwankender RC Oszillator Frequenz auftritt. Klingt auch logisch. Ändert sich der Takt (z.B. über die Temperatur ect...) verliert der Dragon die synchronisation. Die wahrscheinlichkeit, die Synchronisation zu verlieren ist natürlich umso höher, desto mehr Daten über die Eindraht Debugschnittstelle übertragen werden müssen. Somit sind wir wieder bei der These von schnitzeltony. Will man wirklich ohne Probleme Debugen, empfiehlt es sich also den AVR mit nem Quarz zu takten :-)
Klaus B. schrieb: > Ich hab diesbezüglich auch mal mit nem FAE von Atmel telefoniert und der > hat mir gesagt, dass dieses Problem insbesondere bei schwankender RC > Oszillator Frequenz auftritt. Klingt auch logisch. Ändert sich der Takt > (z.B. über die Temperatur ect...) verliert der Dragon die > synchronisation. > ... > > Will man wirklich ohne Probleme Debugen, empfiehlt es sich also den AVR > mit nem Quarz zu takten :-) Also so richtig glücklich macht mich die Antwort, die Du von von Atmel hast nicht weil - ich bei vielen meiner Anwendungen auf ein schlankes Design achten muss. Kurz: Ich hab keinen Bock auf Quarze :-)) - ich meine, in Foren gelesen zu haben, JTAG MK2 hätte das Problem nicht. Was hat der, was AVRDragon nicht hat (außer dem Preis)? - Grundsätzlich sollte Debug-Wire innerhalb eines Frequenzbereichs (sagen wir konservativ 1-8MHz) korrekt funktionieren. AVRDragon muss sich also zu Beginn der Sitzung darauf einstellen was der Controller ihm anbietet. Die Änderung der Frequenz kann sich dann eigentlich nur auf den Zeitraum einer Debug-Sitzung beziehen. Mit Fehlerbedingungen dauern meine Sitzungen maximal 10s :-( Wie soll sich Temperatur oder Spannung (ich hab's mit einem guten Labornetzteil versucht) innerhalb von 10s ändern? Ich hatte vorgestern eine Mail an Atmel geschickt ('damals' hatte ich aber noch nicht so viel getestet). Heute kam eine Mail und es wurde nach mehr Information gefragt, die ich dann auch brav beantwortet habe. Es bleibt spannend...
Da es bzgl. des Dragons immer wieder Fragen gibt, wäre es doch nicht schlecht, wenn ein Drachenbendiger seine Erfahrungen (Einstellungen, Pull-Ups, evtl. Serienwiderstände, Leitungslängen usw.) einmal in der Artikelsammlung genauer beschreibt. Weiterhin wäre es schön dort einige Tips und Tricks niedergeschrieben zu sehen. Ich selbst habe meinen Drachen bisher nur als JTAG-Debugger am Pollin-Board (Mega16) zum Laufen bekommen. Der Versuch via DebugWire am Mega88 ist auch gescheitert.
Hallo, ich habe soeben Antwort bekommen: Meine Fehlerbeschreibung geht an die 'publications division' und man hofft den Fehler im nächsten Release zu beheben. Das hätte was...
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.