mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Probleme mit DRAGON


Autor: Klaus B. (nuccleon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marcel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schalte mal das Optimierungs-Zeugs aus.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Klaus B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Klaus B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du Antwort hast, poste sie hier ;-)

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.