Debugging AVR unter Linux mit AVaRICE und Eclipse funktioniert fast: No source available

[Torsten R. (dode)]

Mir gelingt es hier zumindest eine Debugging-Session zu starten, ich 
lande in main(), kann anscheinend auch Steppen - bekomme aber "No source 
available for "<adress>"" zu sehen, siehe Screenshot.

Die Konfiguration ist:

- AVR Atmega328P
- AVR JTAGICEmkII
- Ubuntu Linux 14.10
- Eclipse Luna
- AVaRICE version 2.13svn20141210 gebaut mit libusb
- GNU gdb (Ubuntu 7.10-1ubuntu2) 7.10

Für die Einstellungen des Projekts in Eclipse bin ich nach dieser 
Anleitung vorgegangen: 
http://avr-eclipse.sourceforge.net/wiki/index.php/Debugging

Debug Configuration:
- Generate Debugging Info: Standard debugging info (-g2)
- Debug Info Format: stabs (avr-gdb / Insight)
- Optimization Level: No Optimizations (-O0)

Konfiguriert hab ich sowohl "GDB Hardware Debugging" als auch "C/C++ 
Attach to Application", bei beiden ist das Ergebnis in etwa dasselbe.

Bei "GDB Hardware Debugging" unter "Startup" hab ich zusätzlich noch 
"Load Symbols" aktiviert und den Pfad zu dem Debug/*.elf angegeben.

Ich mache dann einen "clean Build" in Eclipse und kann sehen, dass das 
Programm in etwa doppelt so groß wird als bei "Release", was denke ich 
an der fehlenden Optimierung und den Debuginformationen liegt.

Das .hex lade ich dann hoch mit:

avrdude -pm328p -cjtag2isp -B10 -Uflash:w:lambda.hex:a

Dann setze ich falls nötig die DWEN Fuse und starte AVaRICE mit:

avarice -2 -w -B10 -j usb :4242

AVaRICE version 2.13svn20141210, Mar  6 2016 17:51:25

JTAG config starting.
Found a device: JTAGICEmkII
Serial number:  07:00:00:00:5c:3c
Reported debugWire device ID: 0x950F
Configured for device ID: 0x950F atmega328p
JTAG config complete.
Preparing the target device for On Chip Debugging.
Waiting for connection on port 4242.

Die Debugausgabe von AVaRICE ist angehängt.

Dann kann ich die Debug-Session in Eclipse starten, bekomme aber "No 
source available for "<adresse>"" und auch "...which has no line number 
information" zu sehen.
Deswegen vermute ich, dass ich das Projekt nicht richtig baue und/oder 
an meiner Konfiguration noch was nicht stimmt.

Kann mir jemand einen Hinweis geben?

[Torsten R. (dode)]

Jetzt hab ichs mehr durch Zufall herausgefunden:

In der "GDB Hardware Debugging" Konfiguration unter "Source" musste ich 
zusätzlich zum "Projekt" Source Lookup Path noch ein "Path Mapping" 
hinzufügen, kurioserweise von dem Pfad der die Sourcedateien enthält 
("Compilation Path") auf denselben Pfad ("Local file system path").

Der Code wird nun mit u.A. den Variablen und deren Werten angezeigt.

Zwei Probleme bleiben aber noch:
- Die Ausführung bleibt nicht bei den Breakpoints stehen. Nur mit einem 
Klick auf "Suspend" bleibt die Ausführung stehen
- "Step Over" klappt wenn nur für einige wenige Schritte, meistens geht 
die Ausführung einfach weiter

Wenn zumindest der erste Punkt noch zu lösen wäre, wäre das mit dem AVR 
Debugging echt der Knaller.

Sehr cool ist auch wie der AVRDude das mit dem DebugWIRE macht, man kann 
obwohl die DWEN Fuse programmiert ist einfach per ISP programmieren und 
nach einem Power-Cycle des Controllers gleich wieder debuggen.

[bernd (Gast)]

Torsten R. schrieb:

> Zwei Probleme bleiben aber noch:
> - Die Ausführung bleibt nicht bei den Breakpoints stehen. Nur mit einem

Unter Eclipse muss man afair irgendwo die Breakpoints erst anschalten, 
vielleicht hilft dir das hier weiter: 
https://www.google.de/search?q=eclipse+enable+breakpoints

> Klick auf "Suspend" bleibt die Ausführung stehen
> - "Step Over" klappt wenn nur für einige wenige Schritte, meistens geht
> die Ausführung einfach weiter

So wie ich das verstanden hab: Es gibt keine Hardware-Breakpoints, 
stattdessen wird ins Flash einen Software-Breakpoint eingefügt. Bei mir 
klappte das steppen in GDP per "n"ext allerdings ganz gut.

>
> Wenn zumindest der erste Punkt noch zu lösen wäre, wäre das mit dem AVR
> Debugging echt der Knaller.
>
> Sehr cool ist auch wie der AVRDude das mit dem DebugWIRE macht, man kann
> obwohl die DWEN Fuse programmiert ist einfach per ISP programmieren und
> nach einem Power-Cycle des Controllers gleich wieder debuggen.

Du kannst sogar per DebugWire programmieren. Ich frage mich, ob es eine 
sinnvolle Möglichkeit ist, DebugWire anzulassen und dann statt úber 
6-pin-ISP (den ich immer schlecht ins Layout bekomme, ohne zwei 
Brücken...) úber DebugWire zu programmieren (und natürlich debuggen)?

[Torsten R. (dode)]

bernd schrieb:

> Unter Eclipse muss man afair irgendwo die Breakpoints erst anschalten,
> vielleicht hilft dir das hier weiter:
> https://www.google.de/search?q=eclipse+enable+breakpoints

Wie man in Eclipse Breakpoints setzt weiß ich von Java-Entwicklung und 
sie funktionieren auch in dem AVR-Eclipse mit einem "normalen" C 
Programm. Die Breakpoints bekommen auch ihr Häkchen, die Ausführung 
bleibt aber nicht an ihnen stehen.

> So wie ich das verstanden hab: Es gibt keine Hardware-Breakpoints,
> stattdessen wird ins Flash einen Software-Breakpoint eingefügt. Bei mir
> klappte das steppen in GDP per "n"ext allerdings ganz gut.

Ja, da werden BREAK Instruktionen eingefügt und dann wieder ersetzt. 
Vielleicht passen bei mir die Zeilennummern im Quellcode nicht zu den 
Debuginformationen auf dem Controller und die BREAKs werden an der 
falschen Stelle gesetzt. Das Steppen könnte auch deswegen nicht klappen.

Ich probier mal den Code anders zu bauen (Debuginformationen?) und auch 
mal direkt in GDB zu debuggen, Danke für den Tipp!

> Du kannst sogar per DebugWire programmieren. Ich frage mich, ob es eine
> sinnvolle Möglichkeit ist, DebugWire anzulassen und dann statt úber
> 6-pin-ISP (den ich immer schlecht ins Layout bekomme, ohne zwei
> Brücken...) úber DebugWire zu programmieren (und natürlich debuggen)?

Könnte interessant sein, aber man hat ja dann auch keinen Reset mehr und 
kann nur noch mit einem Programmer programmieren, der debugWIRE kann. 
Das fände ich ein bisschen schade.

[Torsten R. (dode)]

Habe nun das Debuggen und Setzen eines Breakpoints direkt in GDB 
versucht, z.B. innerhalb des Mainloop in main():

(gdb) break lambda.c:74
Haltepunkt 1 at 0x2ae2: file ../lambda.c, line 74.

auch hier bleibt dann die Ausführung nach "continue" nicht stehen.

Anscheinend werden also die BREAK Instruktionen nicht eingefügt.

Setze ich mittels inline Assembly manuell einen permanenten Breakpoint 
in einer Zeile in der die Ausführung stoppen soll:

asm("break");

bleibt die Ausführung dort stehen:

(gdb) target remote localhost:4242
Remote debugging using localhost:4242
0x00000000 in __vectors ()
(gdb) continue
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
measure () at ../sensors.c:110
110             asm("break");

und ich kann Werte von Variablen ansehen usw. Versuche ich zu steppen, 
sagt GDB:

(gdb) next
measure () at ../sensors.c:110
110             asm("break");
The program is stopped at a permanent breakpoint, but GDB does not know
how to step past a permanent breakpoint on this architecture.  Try using
a command like `return' or `jump' to continue execution.

und ich kann mit jump zur nächsten Zeile springen und die Ausführung 
fortsetzen. Das funktioniert auch prima in Eclipse (siehe Anhang).

Also jetzt rausfinden, warum die BREAK Instruktion nicht eingefügt 
wird..!

[nur mal so (Gast)]

Torsten R. schrieb:
> GDB does not know
> how to step past a permanent breakpoint on this architecture.

Du benutzt avr-gdb?

[bernd (Gast)]

nur mal so schrieb:
> Torsten R. schrieb:
>> GDB does not know
>> how to step past a permanent breakpoint on this architecture.
>
> Du benutzt avr-gdb?

Ah, stimmt! Das war auch mal bei mir das Problem :). Wie konnte ich das 
nur vergesen.

[Torsten R. (dode)]

nur mal so schrieb:

> Du benutzt avr-gdb?

Ja, sicher. Wenn man den "normalen" GDB verwendet, sieht man das ja 
sofort:

(gdb) target remote localhost:4242
Remote debugging using localhost:4242
Python Exception <class 'NameError'> Installation error: gdb.execute_unwinders function is missing: 
0x000875c0 in ?? ()

[QuietDragon (Gast)]

Gibt es mittlerweile eine Moeglichkeit zu steppen? Ich haenge naemlich 
an genau dem gleichen Problem fest.

[Torsten R. (dode)]

QuietDragon schrieb:
> Gibt es mittlerweile eine Moeglichkeit zu steppen?

Von meiner Seite leider nicht. Ich behelfe mich noch mit permanenten 
Breakpoints.

Habe übrigens auch hier die Frage gestellt: 
http://electronics.stackexchange.com/q/221970/65699

Wenn ich dazu komme würde ich mir gerne mal AVaRICE anschauen und 
versuchen zu verstehen was da gemacht wird und was evtl. schief gehen 
könnte.

> Ich haenge naemlich an genau dem gleichen Problem fest.

Auch mit dem JTAGICEmkII oder dem Dragon? Falls letzteres, könnten wir 
die Debugger ja schon mal ausschließen.