Hallo Gemeinde, schon seit einigen Jahren lese ich hier in diesem super Forum und konnte auch immer eine Lösung zu meinen Problemen finden. Vielen Dank an die vielen Mitglieder die hier ihre Zeit opfern um anderen Menschen zu Helfen! Nun zu meinem Anliegen. Ich versuche jetzt schon seit einigen Tagen den Serial Bootloader von AVR2054 http://www.atmel.com/Images/AVR2054.zip so zum laufen zu bekommen, dass ich ihn debuggen kann. Folgende Hardware/Software habe ich im Einsatz: AVR JTAGICE mkII via PDI an einem XMEGA256A3U AVRStudio 4 AVRStudio 5.1 AVRStudio 6 WinAVR-20100110 Ich habe die main-Funktion so erweitert, dass eine LED beim Ausführen getoggelt wird. Übersetzten und den Code übertragen scheint zu funktionieren da die LED blinkt. Beim debuggen werden aber keine breakpoints angenommen und es wird auch nur assembler angezeigt. Folgendes habe ich probiert: Im Verzeichnis \Serial_Bootloader_2_1_0\Embedded_Bootloader_src\ befindet sich die Datei bootloader.aps. Diese öffnet ein Projekt bootloader im AVR Studio 4. Die Main-Funktion habe ich wie beschrieben angepasst und breakpoints gesetzt. Fehlermeldung: Debugger: 'Break at line application\common\src\bootloader.c:43' has been disabled. Unable to bind line 43 in file "application\common\src\bootloader.c" to a program memory address. Nochmal die AppNote gelesen und festgestellt, dass da vom AVR Studio 5 die Rede ist. Also im Verzeichnis \Serial_Bootloader_2_1_0\Embedded_Bootloader_src\as5_projects\ die Datei Atxmega256A3.avrsln mit dem AVR Studio 5.1 geöffnet. Man musste noch das korrekte Makefile wählen und los gings... Das kompilieren und Übertragen lief problemlos aber der Debugger zeigte wieder nur Assembler an. Im Fenster "Call Stack" stand folgende Information: Atxmega256A3.elf! no-debug-info Das gleiche Fehlerbild bekomme ich auch wenn ich die Datei Atxmega256A3.avrsln mit dem AVR Studio 6 öffne und die beschriebenen Schritte ausführe. Kann mir jemand sagen was ich machen muss um im C-code zu debuggen? Vielen Dank für eure Hilfe Chris
:
Verschoben durch Moderator
@Moderator Ich stelle grad fest, dass ich ins falsche Forum geschrieben habe. Könntest du den Beitrag bitte ins GCC-forum verschieben. Vielen Dank Chris
Chris schrieb: > Könntest du den Beitrag bitte ins GCC-forum verschieben. Nein, von daher habe ich ihn hierher geschoben. Du hast, entgegen deiner Auffassung, kein Problem mit dem GCC (daher konnte dir dort auch keiner helfen), sondern eins mit AVR Studio, Atmel Studio, wie auch immer. Wenn du wissen möchtest, wie man den GCC dazu bringt, Debuginformationen auszugeben: Option -g bzw. seine Verwandten, insbesondere -gdwarf-2 oder -gdwarf-4. Aber ich fürchte, dass dich diese Information der Lösung deines Problems halt kein Stück weiterbringt.
Kann man denn mit dem GCC schrittweise debuggen, ggf. breakpoints nutzen? Wenn das so ist, bräuchte ich ja kein AVR / Atmel Studio. Chris
Chris schrieb: > Kann man denn mit dem GCC schrittweise debuggen, ggf. breakpoints > nutzen? Der GCC ist ein Compiler. Der macht aus C-Code Assemblercode, nicht mehr und nicht weniger. Als Hilfe für einen Debugger kann er dabei im Assemblercode noch Zusatzinformationen hinterlassen, die der Assembler dann in den Objektcode übernimmt. Von dort kann sie sich ein Debugger rauspicken. > Wenn das so ist, bräuchte ich ja kein AVR / Atmel Studio. Im Prinzip nicht. Der zugehörige Debugger heißt GDB (bzw. in seiner Inkarnation als AVR-GDB), und er kann über einen sogenannten Proxy namens AVaRICE auch mit einem JTAGICE oder AVR Dragon reden, um ein In-system-Debugging zu realisieren. Freunde diverser IDEs wickeln dann aber üblicherweise über den GDB noch ein irgendwie geartetes GUI darüber; die Palette reicht dabei von Vim und Emacs über allerlei spezielle Oberflächen bis zu Eclipse oder QtCreator. Aber: da dies allesamt generische Programmierumgebungen sind, die nicht speziell nur den AVR zum Ziel haben, ist ein wenig mehr Handarbeit angesagt, wenn man die Kombination AVR-GCC (+ Assembler + Linker), AVR-GDB und AVaRICE darin "zum Spielen" bekommen will.
Damit dieser GDB Debugger aber den Sourcecode mit den entsprechenden Stellen im Assembler Code verknüpfen kann, müssen aber auch die Debug Zusatz Informationen korrekt sein?! Das sind sie scheinbar aber nicht, da ja im AVR Studio auch nur Assembler beim debuggen angezeigt wird. Ein make clean und ein rebuild at leider auch keine Verbesserung gebracht. Ist es nötig dem Compiler noch eine Option für diese Zusatzinformationen zu übergeben? Chris
Chris schrieb: > Damit dieser GDB Debugger aber den Sourcecode mit den entsprechenden > Stellen im Assembler Code verknüpfen kann, müssen aber auch die Debug > Zusatz Informationen korrekt sein?! Ja. > Das sind sie scheinbar aber nicht, da ja im AVR Studio auch nur > Assembler beim debuggen angezeigt wird. Nun, unter der Annahme, dass das AVR Studio die Debuginformationen richtig auswerten kann. Erfahrungsgemäß ist der GDB an dieser Stelle deutlich sauberer gearbeitet als der AVR-Studio-Debugger. Im GDB kann man sowohl mit dem alten stabs-Format als auch mit den diversen DWARF-Formaten gut arbeiten, so gut, wie die jeweiligen Formate überhaupt in der Lage sind, die gewünschte Information zu transpor- tieren. AVR Studio versteht nur einen ganz kleinen Teil dieser Liste, und vom Parser wurde berichtet, dass er auch schon mal komplett abstürzt, wenn da Informationen drin sind, die er nicht kennt (statt sie einfach zu ignorieren). Was natürlich noch hinzu kommt ist, dass nicht jede Zeile C-Code 1:1 irgendeinen Assemblercode ergibt, wenn man (was empfehlenswert ist) die Optimierungen einschaltet. > Ist es nötig dem Compiler noch eine Option für diese > Zusatzinformationen zu übergeben? Ja, schrieb ich oben bereits: -g wählt das Default-Debugformat aus. -gstabs, -gdwarf-2, -gdwarf-3, -gdwarf-4 wählen ein bestimmtes Format explizit aus. AVR Studio versteht meines Wissens nur -gdwarf-2, sollte diese Option aber auch freiwillig ins Makefile einbauen. Habe gerade mal reingesehen, die mitgelieferten Makefiles haben diese Option allerdings standardmäßig deaktiviert:
1 | ifeq ($(BUILD_CONFIGURATION), DEBUG) |
2 | CFLAGS += -g |
3 | endif # DEBUG |
Wenn man mit »make BUILD_CONFIGURATION=DEBUG« baut, werden sie aktiviert. (Es gibt aber keinen vernünftigen Grund, warum man das so verkorkst implementieren will, zumindest nicht für den GCC. Man kann die Debuginformationen auch grundsätzlich mit anfordern, ohne dass das die Optimierung beeinflussen würde.) Inwiefern das durch die jeweiligen Atmel-Studio-Projekt-Dateien genauso gehandhabt wird, müsstest du in jenen selbst nachschauen.
Angehängte Dateien:
-
Re-Mapper.PNG
21 KB
Hallo Jörg, erstmal vielen Dank für deine Hilfe. Ich habe jetzt folgendes gemacht: Das makfile wie folgt geändert:
1 | PREINCLUDE = configuration.h |
2 | |
3 | #BUILD_CONFIGURATION = RELEASE |
4 | BUILD_CONFIGURATION = DEBUG |
5 | . |
6 | . |
7 | . |
8 | #------------------------------------------------------------------------------- |
9 | # Compiler flags: |
10 | #------------------------------------------------------------------------------- |
11 | CFLAGS = -O0 |
12 | CFLAGS += -c |
13 | CFLAGS += -std=gnu99 |
14 | ifeq ($(BUILD_CONFIGURATION), DEBUG) |
15 | CFLAGS += -gdwarf-2 |
16 | endif # DEBUG |
Übersetzen im AS5 klappt soweit ohne Probleme. Beim deguggen wird leider immernoch assembler angezeigt. Ich habe nochmal versucht nur das erzeugte Objekt-file zu debuggen, mit folgender Fehlermeldung, s. Anhang Der Re-Mapper sucht nach einem file libgcc.S, in einem mir unbekannten Pfad. Was ist das für eine Datei? Chris
Chris schrieb: > Der Re-Mapper sucht nach einem file libgcc.S, in einem mir unbekannten > Pfad. Was ist das für eine Datei? Die gehört zum GCC. Eigentlich hätten diejenigen, die die Toolchain zusammenstellen, besser ein »avr-strip -g« über ihre Bibliotheken schicken sollen, denn was nützen dir die Debuginformationen da drin, wenn du den Sourcecode dafür sowieso nicht auf der Platte liegen hast? Du kannst aber all diese Dateien auch einfach ignorieren im Remapper. Dann kann der Debugger diese Stellen halt nicht als Sourcecode anzeigen, aber das ist nicht tragisch. Sie sind für dich einfach eine "Blackbox".
Diese Makefiles, die dabei liegen, sind irgendwie ziemlich verknispelt. Aus irgendeinem Grunde wollen sie da offenbar ein eigenes Linkerscript benutzen, das scheint die Ursache zu sein, dass die DWARF-2-Information dann wieder aus dem ELF-File verschwindet (und stattdessen stabs auftauchen). Kommentier' mal die Zeile aus dem entsprechenden Makefile aus:
1 | LINKER_FLAGS += -Wl,--script=./../../linkerScr/atmega1281.ld |
und schau, ob du das dann debuggen kannst. Die Optimierungen würde ich übrigens eingeschaltet lassen, schließlich haben Bootloader meist nur einen knapp bemessenen Platz im Controller.
Hallo Jörg, leider gibt es auch mit auskommentierter Zeile
1 | #LINKER_FLAGS += -Wl,--script=./../../linkerScr/avrxmega256A3.ld |
keine Erfloge zu verbuchen. Es ist kein debuggen im Projekt und leider auch kein debuggen mit dem .elf Objektfile möglich. Die Optimierung habe ich auch wieder auf den Ursprünglichen Zustand geändert.
1 | CFLAGS = -Os |
Mir ist noch aufgefallen, dass der Debugger nach dem download gleich startet, normalerweise wartet er ja vor dem ersten Befehl, oder? Chris
Chris schrieb: > Es ist kein debuggen im Projekt und leider > auch kein debuggen mit dem .elf Objektfile möglich. Ich glaube, dann wäre es an der Zeit, den Atmel-Support zu belästigen. Wenn sie schon eine Appnote mitsamt AVR-Studio-Projekt ausliefern, dann sollte sich das auch mit dem AVR Studio debuggen lassen, finde ich. Was sagt denn das Kommando »avr-objdump -h Bootloader.elf«? Bei mir kommt da:
1 | Bootloader.elf: file format elf32-avr |
2 | |
3 | Sections: |
4 | Idx Name Size VMA LMA File off Algn |
5 | 0 .text 000009c2 00000000 00000000 00000094 2**1 |
6 | CONTENTS, ALLOC, LOAD, READONLY, CODE |
7 | 1 .data 00000020 00802000 000009c2 00000a56 2**0 |
8 | CONTENTS, ALLOC, LOAD, DATA |
9 | 2 .bss 00000091 00802020 00802020 00000a76 2**0 |
10 | ALLOC |
11 | 3 .stab 000008f4 00000000 00000000 00000a78 2**2 |
12 | CONTENTS, READONLY, DEBUGGING |
13 | 4 .stabstr 000000db 00000000 00000000 0000136c 2**0 |
14 | CONTENTS, READONLY, DEBUGGING |
15 | 5 .comment 00000011 00000000 00000000 00001447 2**0 |
16 | CONTENTS, READONLY |
17 | 6 .debug_aranges 00000170 00000000 00000000 00001458 2**0 |
18 | CONTENTS, READONLY, DEBUGGING |
19 | 7 .debug_info 00001db1 00000000 00000000 000015c8 2**0 |
20 | CONTENTS, READONLY, DEBUGGING |
21 | 8 .debug_abbrev 00000a5f 00000000 00000000 00003379 2**0 |
22 | CONTENTS, READONLY, DEBUGGING |
23 | 9 .debug_line 00000bbf 00000000 00000000 00003dd8 2**0 |
24 | CONTENTS, READONLY, DEBUGGING |
25 | 10 .debug_frame 000002e4 00000000 00000000 00004998 2**2 |
26 | CONTENTS, READONLY, DEBUGGING |
27 | 11 .debug_str 000010de 00000000 00000000 00004c7c 2**0 |
28 | CONTENTS, READONLY, DEBUGGING |
29 | 12 .debug_loc 000007a4 00000000 00000000 00005d5a 2**0 |
30 | CONTENTS, READONLY, DEBUGGING |
31 | 13 .debug_ranges 00000118 00000000 00000000 000064fe 2**0 |
32 | CONTENTS, READONLY, DEBUGGING |
Die .stab und .stabstr sollten bei dir nicht auftauchen; bei mir hat die verwendete System- und GCC-Bibliothek ihre Debuginformationen im stabs-Format. Wichtig sind all die .debug_*-Sections, denn darin liegt die DWARF-Information. Mit »avr-readelf --debug-dump Bootloader.elf« kann man sich auch die Details der DWARF-Infos anzeigen lassen. > Mir ist noch aufgefallen, dass der Debugger nach dem download gleich > startet, normalerweise wartet er ja vor dem ersten Befehl, oder? Dazu kenne ich AVR Studio zu wenig. Kann aber gut ein Folgefehler sein: wenn er keine benutzbaren Debuginformationen findet, dann kennt er natürlich auch die Adresse von main() nicht, bei der er sonst anhalten würde.
Hallo Jörg, ich habe gute Neuigkeiten. Ein Kollege meinte Gestern zu mir ich sollte es mal mit dem AVR Studio 6 probieren, und siehe da, es klappt! Kompilieren und debuggen ist mit folgender Einstellung im Makefile möglich:
1 | #BUILD_CONFIGURATION = RELEASE |
2 | BUILD_CONFIGURATION = DEBUG |
So wie du es gesagt hattest. Vielen Dank für deine Hilfe! Könntest du bitte noch dem Thread Titel ein "solved" hinzufügen? Danke
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.