Debuggen mit JTAG ICE MKII findet nicht alle Sourcen

[Loocee L. (loocee)]

Hallo zusammen,

habe bereits etwas die Suchfunktion in Anspruch genommen, bin aber
aufgrund der Komplexität der Anforderung an die Formulierung
gescheitert bzw. schlichtweg nicht fündig geworden. Vielleicht kann
mir jemand einen Link auf einen bestehenden Beitrag für eine Lösung
nennen, ansonsten bitte ich so um Hilfe:

Konfiguration:

- Atmel Studio 4.18
- JTAG ICE MKII original (kein Nachbau)
- WinAVR-20100110 (die letzte mir bekannte Version)
- Prozessor z.B. ATMega644 oder ATxMega128
- benutze das JTAG Interface

Das Problem:

Beim Durchsteppen mit dem Debugger findet Atmel Studio nicht alle
Sourcen, zeigt also dann ggf. nichts an, man sieht dann plötzlich
nicht an welcher Stelle man im Code steht. Erst wenn man einen im
Code bekannten (und noch sichtbaren) Breakpoint setzt und dann den
Code bis dorthin laufen lässt (F5) findet man wieder eine
hervorgehobene Code-Zeile wo man sich befindet. Insbesondere
auffällig ist das bei _delay_ms(...) aber auch anderen Low-Level
Routinen.

Gibt es irgendwelche Anforderungen der Kombination Atmel Studio und
WinAVR, oder muss man den beteiligten Programme durch Settings noch
etwas mitteilen was ich nicht weiss? Oder gibt es spezielle Compiler
Flags für eine Debug-Version? Reihenfolge der Installation von
Studio und WinAVR (die beiden Beteiligten sind auf ihre
vorgeschlagenen Default-Verzeichnisse instelliert)?

Gruß

loocee

[holger (Gast)]

>Beim Durchsteppen mit dem Debugger findet Atmel Studio nicht alle
>Sourcen,

Die Sourcen von Librarys sind meist nicht vorhanden.
Über Library Funktionen machst du halt ein StepOver.
Also sowas wie (s)printf, itoa, strcpy, _delay_ms.
Im Prinzip alles was im Projekt nicht als C-Code vorhanden ist.

[Loocee L. (loocee)]

holger schrieb:
> Die Sourcen von Librarys sind meist nicht vorhanden.

Diesr Code ist normalerweise "von Hand" zu finden, so z.B ist
_delay_ms () in der Header Datei delay.h (irgendwo im WinAVR-20100110) 
auscodiert.

Einleuchtend wäre es wenn der Compiler nur vohandene Objects
einbindet, so compiliert er aber die Source mit ein .....

[holger (Gast)]

>Diesr Code ist normalerweise "von Hand" zu finden, so z.B ist
>_delay_ms () in der Header Datei delay.h (irgendwo im WinAVR-20100110)
>auscodiert.

_delay_ms ist jetzt aber ein schlechtes Beispiel.
Ohne Optimierung ist _delay_ms quasi unbrauchbar.
Siehe die Warnung in delay.h. Da fängst du dir
Floating Point Funktionen ein.

Mit Optimierung brauchst du deinen Debugger gar nicht erst anwerfen.
Da darf der Compiler alles so umbauen wie er möchte. Da gehen durchaus
ganze Codeteile oder Variablen flöten weil er sie nicht braucht.

Oder kurz zusammengefasst: Willst du _delay_ms verwenden?
Dann debugge nicht. Wenn du debuggen willst verwende _delay_ms nicht;)

[Loocee L. (loocee)]

holger schrieb:

> _delay_ms ist jetzt aber ein schlechtes Beispiel.
> Ohne Optimierung ist _delay_ms quasi unbrauchbar.
> Siehe die Warnung in delay.h. Da fängst du dir
> Floating Point Funktionen ein.

Die Warnings kenne ich ....

Ein Aufruf von _delay_ms(...) mit Konstante als Übergabe
ergibt festverdrahteten Inline-Code und keine Floating Point
Operationen. Das würde man sehr schnell merken da sonst
FP Code (Grösse!) dazugelinkt wird .....

Klar kann man sich die Delays für den Debug-Fall mit
ifdefs ausblenden, aber ich hatte mir aus Erfahrung mit
anderen Debuggern erwartet dass so etwas einwandfrei
unterstützt wird.