Forum: Compiler & IDEs Probleme bei Debugging von GCC mit AVR Dragon


von Thomas Bauer (Gast)


Angehängte Dateien:

Lesenswert?

Ich benutze AVR-Studio 4.13 mit WinAVR-20070525, um auf dem ATTiny13 zu 
entwickeln. Zum Programmieren und Debuggen verwende ich einen AVR 
Dragon.

Mein Problem ist nun, dass das Debuggen von C-Code nicht funktioniert.
Starte ich das Debuggen, wird über Debugwire eine Verbindung zum Target 
hergestellt und AVR-Studio versucht, den Programmcode zu übertragen 
(loading program memory ...). Nach einigen Sekunden bricht das Ganze mit 
folgenden Meldungen ab:

"Coordinator: Error when writing memory contents to the debug platform.
Coordinator: Error loading object file."
"Platform has been disconnected, leaving debug mode"

Interessanterweise funktioniert das Debugging von Assembercode 
problemlos. Im  Message-Fenster wird gemeldet:
"Loaded objectfile: C:\AVR-Controller\testasm\testasm.obj"
und das Programm läuft. Nur so habe ich überhaupt die Möglichkeit, die 
DWEN-Fuse wieder zurückzusetzen.

Scheinbar gibt es ein Problem mit dem Objektfile beim GCC. Ich habe die 
Option -gdwarf-2 gewählt. Dann sollte doch das generierte .elf File 
verwendet werden, oder?

Ich habe das Makefile und die Compiler-Meldungen für ein kleines 
Testprogramm angehängt.
Hat jemand einen heißen Tip, was ich falsch gemacht habe?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Wie lang ist dein Kabel, und was hast du am /RESET-Pin noch
angeschaltet?

von Thomas Bauer (Gast)


Lesenswert?

Ich habe die Lösung jetzt gefunden:
Es liegt wohl an der CLKDIV8 Fuse, mit der ich den Systemtakt von 4,8MHz 
auf 600kHz reduziert habe. Wenn ich diese Fuse lösche und stattdessen 
den Systemtakt programmatisch über das Clock Prescaler Register teile, 
funktioniert das Debugging problemlos.

Ich habe schon an anderer Stelle hier im Forum gelesen, dass die CLKDIV8 
Fuse Probleme macht im Zusammenhang mit Debugwire. Hätte ich also gleich 
probieren können :-(

Warum das so ist und warum es mit Assemblercode trotzdem funktioniert 
hat, wird mir trotzdem ein Rätsel bleiben.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Thomas Bauer wrote:

> Ich habe schon an anderer Stelle hier im Forum gelesen, dass die CLKDIV8
> Fuse Probleme macht im Zusammenhang mit Debugwire. Hätte ich also gleich
> probieren können :-(

Frag mal bitte bei avr -at- atmel.com nach, ob sie dafür eine
Erklärung bzw. eine empfohlene Vorgehensweise haben.

> Warum das so ist und warum es mit Assemblercode trotzdem funktioniert
> hat, wird mir trotzdem ein Rätsel bleiben.

Meine Vermutung ist einfach, dass der Binärcode deines Assemblerprojekts
klein ist und damit die Wahrscheinlichkeit eines Übertragungsfehlers
geringer ist als beim C-Projekt.

von Thomas Bauer (Gast)


Lesenswert?

Antwort auf meine Support-Anfrage bei Atmel:
1
As the debugWIRE system shares system clock with the SPI module, 
2
the PRSPI bit needs to be cleared. 
3
As you can see from figure 8-1 "Clock Distribution" on page 28, 
4
the SPI module (clkI/O) is connected to the system clock through the System Clock Prescaler.
5
This means the speed of debugWire will increase/decrease when the clkI/O is higher/lower. 
6
The lowest recommended system clock frequency to run debugWIRE on is 128KHz.

Das erklärt leider nicht viel. Prinzipiell sollte der ATTiny13 also mit 
programmierter CKDIV8-Fuse (Systemtakt 600kHz) ausreichend schnell sein. 
Die SPIEN-Fuse (PRSPI ?!) ist auch programmiert.

Dass es an der Kabellänge liegt, halte ich für unwahrscheinlich. Dann 
sollte das Problem eher bei höheren Taktfrequenzen auftreten.

Vielleicht ist es ja doch ein Bug im AVR-Studio, da ähnliche Probleme 
sowohl mit anderen Controllern, anderen Frequenzen als auch mit anderen 
Debuggern (MKII) auftreten. Die einzigen Gemeinsamkeiten sind AVR-Studio 
und das undokumentierte debugWire-Protokoll.
Siehe auch Beitrag "debugWire funktioniert nicht richtig ?"

Eine programmatische Änderung des Systemtaktes bringt übrigens das 
gleiche Ergebnis, wie das Programmieren der CKDIV8-Fuse. (Ich hatte beim 
ersten Versuch die timed sequence nicht eingehalten, die Taktfrequenz 
blieb daher unverändert.)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

AVR Studio wird da nicht viel anrichten können.  Es ist hier auf
Gedeih und Verderb dem ICE ausgeliefert, das das gesamte Echtzeit-
Handling ja vornimmt.  Ob das nun ein JTAG ICE mkII oder ein AVR
Dragon ist, spielt dabei keine Geige: beide fahren ja im Prinzip
mit den gleichen Firmware-Modulen.

Dass debugWIRE als 1-Wire-Bus insgesamt anfälliger ist als bspw.
JTAG, ist mir auch schon aufgefallen.  Im Grunde genommen verwundert
es auch nicht sehr, das Ganze hängt halt massiv mit dem Timing
irgendwelcher RC-Konstanten zusammen.  Ich nehme die eigentliche
Datenübertragung (also das Neuflashen des ROMs) daher immer im ISP-Modus
vor und nehme debugWIRE wirklich nur zum Debuggen.  Das müsste
prinzipiell auch mit dem AVR Studio funktionieren, ist dort aber
vermutlich noch umständlicher als bei AVRDUDE/AVaRICE.

von Bernd A. (Gast)


Lesenswert?

HILFE!

Wie komme ich aus dem bescheuerten debug-Modus raus?
Ich habe meinen ATmega88 über den Dragon debugt und gerade als ich den 
debug-Modus beenden wollte funktioniert die Kommunikation nicht mehr.
Randdaten: AVR-Studio 4.18.692, WinAVR-20100110, ich programmiere in C, 
ATmega88, 8 MHz,
Maßnahmen: AVR-Studuio schon 10 mal neugestartet, Dragon ebenso oft 
disconnected und wieder connected, USB-Kabel getauscht, usw.

Hatte schon mal öfter Probleme, wegen Beschaltung am Reset-Pin.
Im moment habe ich den ATmega in einem STeckbrett und nur VCC,GND und 
Reset-Pin angeschlossen

Ich will doch nur den Debug-Modus beenden...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Kannst du bitte für einen unverwandten Beitrag einen eigenen Thread
starten?

Danke.

von Bernd A. (Gast)


Lesenswert?

Ich findeschon das er verwandt ist: Ich habe Probleme beim debugging von 
GCC mit AVR Dragon - Kommunikation wird nicht mehr aufgebaut

von Frederik K. (n0ll4k)


Lesenswert?

Ich hatte letztens ein ähnliches Problem und konnte nicht mehr auf den 
AVR drauf. Ich hab dann auf dem Dragon die Stiftleisten und einen Sockel 
aufgelötet und verbunden und anschließend mit HVPP den ATMega 
zurückgesetzt, danach funktinierte wieder alles super.

von Michael G. (teslazwerg)


Lesenswert?

ein Workaround, das(der?) mir beim Dragon geholfen hat:

- AVR Studio beenden
- Dragon resetten (USB-Stecker ziehen und wieder verbinden)
- AVR Studio starten
- Compiler-optimierung abschalten
  (Project -> Configuration Options -> Optimization: -O0)
- Debuggen starten

So hab ich es zumindest bisher hin bekommen wieder in den Debug-Modus zu 
kommen um Debug-Wire abzuschalten.

Es scheint fast so, als ob das Problem was mit der Größe des Programms 
zu tun hat.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Man könnte ja auch einfach AVRDUDE benutzen...

von Michael G. (teslazwerg)


Lesenswert?

Jörg Wunsch schrieb:
> Man könnte ja auch einfach AVRDUDE benutzen...

und damit kann ich den Debug-Wire Modus meines Controllers wieder 
aubschalten?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Michael Gras schrieb:
> Jörg Wunsch schrieb:
>> Man könnte ja auch einfach AVRDUDE benutzen...
>
> und damit kann ich den Debug-Wire Modus meines Controllers wieder
> aubschalten?

Na klar, sonst hätte ich es doch nicht vorgeschlagen. ;-)

Um mal TFM zu zitieren:

   debugWire limitations
...
     The only way back from debugWire mode is to initiate a special
     sequence of commands to the JTAG ICE mkII (or AVR Dragon), so the
     debugWire mode will be temporarily disabled, and the target can
     be accessed using normal ISP programming.  This sequence is
     automatically initiated by using the JTAG ICE mkII or AVR Dragon
     in ISP mode, when they detect that ISP mode cannot be entered.

Kurzform: du gibst dein gewünschtes ISP-Kommando ein, das geht
schief, AVRDUDE versucht daraufhin, den debugWIRE-Modus auszuschalten.
Danach muss man sich zwingend vom ICE/Dragon abmelden (d. h., bei
AVRDUDE beendet sich dieses), danach das gleiche Kommando nochmal
eingeben (also: <Cursor nach oben>, <Enter>).  Das Kommando muss
dabei nicht zwinged die DWEN-Fuse selbst anfassen, es darf genauso
gut ein ganz normales flash write etc. sein.  Wenn man die DWEN-Fuse
nicht modifiziert hat, befindet sich der Controller nach dem
nächsten power-on-Reset erneut im debugWIRE-Modus.

von Michael G. (teslazwerg)


Lesenswert?

sehr schön, wieder was gelernt :)

Bitte 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
Noch kein Account? Hier anmelden.