Forum: Compiler & IDEs Zu viele Symbole werden gestrippt (Code zu klein)


von funker (Gast)


Lesenswert?

Hallo zusammen,

ich nutze AVR-GCC um Code für einen ATmega128RFA1 zu kompilieren. 
Ursprünglich nutzte ich WinAVR-20100110, nun möchte ich aber einen 
neueren Kompiler nutzen. Ich habe also nun zwei zur Verfügung: den aus 
WinAVR in Version 4.3.3 und einen in Version 4.8.1 aus der Atmel 
AVR-Toolchain (für 8-Bit AVR).

Die benutzten Makefiles sind stets dieselben, der Unterschied liegt nur 
darin, dass ich in meiner Konsole entweder den Pfad zu WinAVR (bin, 
avr/bin und utils) dem vorhandenen voranstelle oder den Pfad zur 
AVR-Toolchain (bin und avr/bin, die Utilities kommen dann auch aus 
Win-AVR - die spielen beim Kompilieren selbst aber keine Rolle, die 
relevanten Tools (avr-gcc, avr-as, ...) liegen ja in bin oder avr/bin 
(dort als gcc, as, ...). Benutzt wird Win7. Es gibt keine Fehler beim 
kompilieren.

Der Build log ist absolut identisch, bis auf die Ausgabe der Größen:


WinAVR:
--------
1
[...]
2
Linking ELF file...
3
Calculating sizes...
4
   text     data      bss      dec      hex  filename
5
  93986     4452     4909   103347    193b3  ./../../bin/Test.elf
6
  93986     4452     4909   103347    193b3  (TOTALS)

AVR-Toolchain:
--------------
1
[...]
2
Linking ELF file...
3
   text     data      bss      dec      hex  filename
4
   4932     4098      240     9270     2436  ./../../bin/Test.elf
5
   4932     4098      240     9270     2436  (TOTALS)

Die erzeugte Größe des Output-Files ist im zweiten Fall viel zu klein. 
Die Größe der zwischendurch erstellten Objektdateien ist aber in beiden 
Fällen sinnvoll (und teilweise sehr groß).

In meinem Listing sehe ich, dass im Fall der AVR-Toolchain eine Menge 
Symbole weggeworfen wird.

Beispiel "BSP_OpenLeds": Für WinAVR findet man dieses Symbol im Listing 
in Sektion "Linker script and memory map", aber im Falle der 
AVR-Toolchain erscheint es unter Sektion "Discarded input sections".

BSP_OpenLeds ist aber eine Funktion, die definitiv benutzt wird!

Irgendwo muss also der Linker völligen Käse machen. Als Optionen wird 
-ffunction-sections dem Kompiler gegeben (um ungenutzte Funktionen 
später heraustrennen zu können) und --gc-sections dem Linker (und zwar 
über -Wl,--gc-sections in Form einer Kompileroption, so dass dieser sie 
korrekt weitergibt).

WinAVR trennt dann auch nur wirklich unbenutztes Zeug heraus, wohingegen 
die AVR-Toolchain auch genutztes heraustrennt.
1
CFLAGS = -Os -std=gnu99 -pipe -c -W -Wall -ffunction-sections -mmcu=atmega128rfa1 -mcall-prologues -fshort-enums -DATMEGA128RFA1 -I./../../inc [eine Menge weiterer -I Includes] -g
2
3
LINKER_FLAGS = -Wl,-Map=./lst/Test.map -Wl,--gc-sections -Wl,--script=./scr/atmega128rfa1.ld -Wl,--section-start=.data=0x800200 -mmcu=atmega128rfa1
(aufgerufen wird avr-gcc mit o.g. LINKER_FLAGS)

Warum in aller Welt verhält sich nun ein neuerer Kompiler/Linker so 
dermaßen anders? Mit einem selbst kompilierten AVR-GCC 4.9.1 passiert 
das gleiche...

Hat jemand sowas auch schon gesehen oder einen Tipp?

Vielen Dank!

Volker

von Oliver S. (oliverso)


Lesenswert?

Die erste Frage ist doch: Funktioniert das Programm? Ja oder nein?

Oliver

von Karl H. (kbuchegg)


Lesenswert?

Ohne Code ist es schwierig, da was zu sagen.
zb könnte ein aggressiveres Inlining da einen Unterschied machen. Wenn 
dann Compiler/Linker auch noch rauskriegen, dass die Funktion (weil 
überall geinlined) eigentlich nicht gebraucht wird und deshalb komplett 
rausfliegt, kann das einen Unterschied ausmachen zum Fall, dass die 
Funktion zwar geinlined wird, aber als Funktion selbst auch noch im 
Programm beibehalten wird.

Funktioniert denn das kleinere Ergebnis?

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Vielleicht wirfst du das -ffunction-sections und -gc-sections ja
erstmal raus?

Die Dinger sind doch in den allermeisten Fällen nur eine Entschuldigung
für die Faulheit des Programmierers, den Überblick darüber zu behalten,
was er in seinem Projekt von alldem, was da aufgeschrieben worden ist,
denn nun tatsächlich braucht.

von Oliver S. (oliverso)


Lesenswert?

Karl Heinz schrieb:
> zb könnte ein aggressiveres Inlining da einen Unterschied machen.

Das ist bei -Os allerdings nicht zu erwarten.

Oliver

von Peter D. (peda)


Lesenswert?

Oliver S. schrieb:
> Das ist bei -Os allerdings nicht zu erwarten.

Zumindest beim WINAVR 2010 wird trotz -Os ungewünscht geinlined.
Man muß es explizit mit:
-fno-inline-small-functions
ausschalten.

von Karl H. (kbuchegg)


Lesenswert?

> Das ist bei -Os allerdings nicht zu erwarten.
>

Die 'Idee' war eigentlich, dass sich unterschiedliche Compilerversionen 
hier zum Beispiel unterschiedlich verhalten könnten.
Wenn also dieselbe Funktion in der einen Compilerversion übrig bleibt 
und in einer anderen Version rausfällt, dann muss das nicht unbedingt 
auf einen Fehler im Compiler hindeuten.

: Bearbeitet durch User
von funker (Gast)


Lesenswert?

Vielen Dank erstmal für die vielen Ratschläge. Gleich kommt die Lösung, 
aber zuerst dies:

@ Oliver S. (oliverso): Nein, es funktioniert nicht und wäre auch nicht 
zu erwarten gewesen. Das Programm nutzt den Atmel BitCloud Stack, der 
alleine schon um die 80 k hat. Aber das hatte ich nicht erwähnt, daher 
ist die Nachfrage natürlich berechtigt. Danke!

@Jörg Wunsch (dl8dtl): Das ist ein naheliegender, sinnvoller Vorschlag, 
danke! Aber hier wird eben ein Atmel BitCloud-Stack benutzt, plus eigene 
Applikation oben drauf, und diese Optimierung wird von Atmel schon in 
den Makefiles eingebaut, weil der Stack naturgemäß viel mehr Funktionen 
anbietet, als eine Applikation später nutzt. Ohne das Rausschmeißen 
ungenutzter Funktionen würde ich wohl den Speicherplatz sprengen (läuft 
auf einem ATmega128RFA mit 128 kB Flash, braucht mit Stack und Treibern 
ohne großartige App schon >103 kB bei Rausschmeißen der ungenutzten 
Funktionen.
Und: Mit WinAVR klappt's ja...

@Karl Heinz (kbuchegg): Ja, genau, es muss nicht am Compiler liegen 
(bzw. eher Linker hier). Das ist tatsächlich hier der Fall. Ich hatte 
gehofft, dass jemand diesem Phänomen schon mal aufgesessen ist, und dann 
sagen kann, schau mal hier oder mal da. Das wurde ja auch erfüllt, denn 
mancher Hinweis von Dritten gibt einem oft den entscheidenden Blick auf 
etwas, was man bisher nicht in Betracht zog (schon alleine das 
Formulieren der Frage brachte mich dazu, selbst noch das ein oder andere 
vorher auszuprobieren und auszuschließen). Aber genug Blabla, jetzt 
kommt die (naheliegende) Lösung:

Im Linker-Script (nebenbei bemerkt von Atmel) haben die eine 
DISCARD-Section eingebaut und schmeißen die .init9-Sektion weg. Da kommt 
aber gemäß AVR-LIBC die main hin. Sehr, sehr schlau. Die Atmel-Leute 
haben stattdessen eine Sektion *(.text.main) nebst KEEP (*(.text.main)) 
eingefügt, aber das funktioniert nicht (bei mir).

Nun habe ich dort wieder *(.init9) und den DISCARD auskommentiert, und 
nun klappt's auch mit den neueren Kompilern (und es ist nicht der 
Kompiler, sondern das ebenfalls neuere AVR-LIBC, das nun in V1.8.0 statt 
1.6.7 (oder so) vorliegt, wobei main schon immer nach .init9 gekommen 
sein dürfte...

Theoretisch müsste es nun auch mit meinem selbstkompilierten GCC 4.9.1 
gegen, nebst selbst kompiliertem AVR-LIBC 1.8.0.

Jörg müsste das wohl am besten beurteilen können, ob es nun an AVR-LIBC 
und dem "komischen" Atmel-Linker-Script lag, aber wie gesagt, nun geht's 
ja.

Nachfrage Off-Topic an Jörg: Du hattest an AVRDUDE gearbeitet, um auch 
mit aktuellen Firmwareversionen von JTAGICE3 programmieren zu können und 
das gibt's als SVN-Snapshot irgendwo. Gibt es bald eine neue, offizielle 
Release, die das unterstützt? So lange muss ich nämlich auf's 
Firmwareupdate meines JTAGICE3 verzichten (und kann nicht vernünftig 
Debuggen, weil ich es nicht ans Atmel-Studio anschließen kann, ohne dass 
es meine Firmware updated). Leider gibt's ja auch noch keine 
OpenSource-Debugging-Möglichkeit mit JTAGICE3, das vermisse ich sehr 
(hätte halt doch einen AVR Dragon kaufen sollen, der wird wenigstens gut 
unterstützt)...

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


Lesenswert?

funker schrieb:

> @Jörg Wunsch (dl8dtl): Das ist ein naheliegender, sinnvoller Vorschlag,
> danke! Aber hier wird eben ein Atmel BitCloud-Stack benutzt, plus eigene
> Applikation oben drauf, und diese Optimierung wird von Atmel schon in
> den Makefiles eingebaut, weil der Stack naturgemäß viel mehr Funktionen
> anbietet, als eine Applikation später nutzt.

Da rächt es sich, dass sie den nicht sauber in Bibliotheken ablegen,
und gegen diese linken.  Aus denen würde sich der Linker nur die
Module krallen, die wirklich referenziert werden.

> Im Linker-Script (nebenbei bemerkt von Atmel) haben die eine
> DISCARD-Section eingebaut und schmeißen die .init9-Sektion weg. Da kommt
> aber gemäß AVR-LIBC die main hin. Sehr, sehr schlau. Die Atmel-Leute
> haben stattdessen eine Sektion *(.text.main) nebst KEEP (*(.text.main))
> eingefügt, aber das funktioniert nicht (bei mir).

Grmpf.  Kaputtgespielt.

Schreib ihnen einen Bugreport.

> Nachfrage Off-Topic an Jörg: Du hattest an AVRDUDE gearbeitet, um auch
> mit aktuellen Firmwareversionen von JTAGICE3 programmieren zu können und
> das gibt's als SVN-Snapshot irgendwo. Gibt es bald eine neue, offizielle
> Release, die das unterstützt?

Ist doch schon drin (seit März 2014).

Allerdings macht es zuweilen Probleme (OSX und wohl teilweise auch
Windows), weil die libusb sich nicht gegen die OS-Treiber für das
HID durchsetzen kann.  Ich erwäge, das Ganze auf libhid umzubauen,
denn damit scheint OpenOCD gut zurecht zu kommen.

Linux und FreeBSD gehen auf jeden Fall damit, auch mit dem neuen
Atmel-ICE.

Nur im AVaRICE hab' ich es immer noch nicht drin.

> Leider gibt's ja auch noch keine
> OpenSource-Debugging-Möglichkeit mit JTAGICE3, das vermisse ich sehr

Doch, AVaRICE kommt mit der 2.er (nicht-CMSIS-DAP-)Firmware des
JTAGICE3 zurecht.  Hab' ich gerade eben wieder benutzt hier.  Bloß
die CMSIS-DAP-Erweiterung bin ich noch nicht angegangen.

von Oliver S. (oliverso)


Lesenswert?

Jörg Wunsch schrieb:
> Grmpf.  Kaputtgespielt.

Sicher? Ich vermute da doch eher einen unzulässigen MischMasch der 
verschiedenen toolchain- Versionen.

Das die aktuelle Atmel-toolchain so kaputt wäre, daß sie main 
"rausoptimiert", hätte sich schon rumgesprochen.

Oliver

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


Lesenswert?

Oliver S. schrieb:
> Sicher?

Es gibt bei AVR + avr-libc keinen vernünftigen Grund, warum man für
ein 08/15-Projekt überhaupt mit custom linker scripts anfangen
müsste.  (Ja, bei ARM ist das anders.)

Außerdem ist der Sprung (bzw. Aufruf) von main() aus .init9 das
dokumentierte Verhalten der avr-libc.

Wenn Atmel das besser weiß, sollen sie's bitte selbst supporten.

: Bearbeitet durch Moderator
von funker (Gast)


Lesenswert?

@ Oliver S. (oliverso):

Nee, nicht die AVR-Toolchain ist "kaputt", sondern das Linker-Script, 
das im BitCloud Stack benutzt wird. In der Atmel AVR-Toolchain sind die 
originalen Linkerscripts von AVR-LIBC drin. Wer also die Atmel Toolchain 
mit den mitgelieferten Linker-Scripts nutzt, hat kein Problem.

Keine Ahnung, warum es im BitCloud-Stack ein eigenes Linker-Script gibt 
(öhm, nun gut, in neueren Versionen haben sie extra Sektionen 
eingeführt, da mag das Sinn machen, wenn man's denn richtig machte). 
Jedenfalls ist es also nie ein Problem irgendeiner Toolchain gewesen, 
sondern nur des mitgelieferten Linker-Scripts im BitCloud-Stack, das man 
für seine BitCloud-App nutzen soll. Vermutlich wäre (zumindest in alten 
Versionen) ein linken gegen die Original-Linker-Scripts aus AVR-LIBC 
auch gegangen...

von funker (Gast)


Lesenswert?

Jörg Wunsch schrieb:
> Ist doch schon drin (seit März 2014).

Dann habe ich was verpasst oder falsch verstanden. Ich hatte mir einen 
AVRDUDE 6.1 (vom 13.3.3014) für Windows kompiliert und es so verstanden, 
dass dieser zwar JTAGICE3 unterstützt, aber nicht mit 
CMSIS-DAP-Firmware. Ich dachte, dazu müsse man einen SVN-Snapshot holen 
und den kompilieren...

> Nur im AVaRICE hab' ich es immer noch nicht drin.

Dann hält mich auch dies noch von einem Firmware-Update ab.

> Doch, AVaRICE kommt mit der 2.er (nicht-CMSIS-DAP-)Firmware des
> JTAGICE3 zurecht.  Hab' ich gerade eben wieder benutzt hier.  Bloß
> die CMSIS-DAP-Erweiterung bin ich noch nicht angegangen.

Habe Version 3.15 drauf (schon seit Kauf). Jetzt sag aber nicht, dass 
das schon eine mit CMSIS-DAP-Firmware ist... Meine PID ist jedenfalls 
noch 0x2110 und nicht 0x2140, wie auf den CMSIS-DAP-Geräten laut 
http://savannah.nongnu.org/bugs/?40615...

Damit müsste AvaRICE dann gehen? Muss ich morgen sofort ausprobieren 
(wenn ich dazu komme)...

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


Lesenswert?

funker schrieb:

>> Nur im AVaRICE hab' ich es immer noch nicht drin.
>
> Dann hält mich auch dies noch von einem Firmware-Update ab.

Sagen wir mal so: wenn du nicht musst, dann solltest du dir den
Upgrade auch nicht antun.  (Müssen tut man nur für Atmel Studio.)

Besser wird davon nämlich fast nichts, wenn man vielleicht davon
absieht, dass es im Prinzip dann auch noch unter USB 1.1 geht (aber
mit saumäßiger Performance), während die nicht-CMSIS-DAP-Firmware
in dieser Hinsicht kaputt war.  Die geht nur auf USB 2.0.

Das Einzige, was daran aus Windows-Sicht besser ist ist, dass
Windows eben immer einen Treiber für HID mitbringt, sodass man
keinen spezifischen Treiber installieren muss.  Nicht-Windows-Systeme
hatten ebendieses Problem jedoch gar nicht erst, denn die bringen für
alle USB-Geräte immer einen low-level-Treiber mit, auf dem die
libusb aufsetzen kann.  (Neuere Windows-Versionen sollen sowas auch
haben, habe ich mir sagen lassen.)

Der ganze HID-Krempel verursacht ein Vielfaches an Overhead in der
Kommunikation.  Da werden jedesmal volle 512 Bytes über den Draht
gefeuert, auch dann, wenn nur ein Byte gesendet werden muss.  Jedes
Antwortpaket muss per Anforderung abgeholt werden (wobei die
Anforderung selbstverfreilich ihre vollen 512 Bytes einnimmt), während
es in der vorigen Firmware freiwillig ankam.  Events hatten in der
vorigen Firmware einen eigenen Interrupt-Endpoint; jetzt muss die
Applikation regelmäßig nach Events pollen (und du vermutest richtig,
wenn du denkst, dass auch das Pollen selbst volle 512 Byte für die
Anforderung und weitere 512 Byte für die Antwort, auch eine leere,
braucht).

> Habe Version 3.15 drauf (schon seit Kauf). Jetzt sag aber nicht, dass
> das schon eine mit CMSIS-DAP-Firmware ist... Meine PID ist jedenfalls
> noch 0x2110 und nicht 0x2140, ..

OK, bei mir ist die nicht-CMSIS-DAP-Version noch eine 2.21 (dezimal),
aber wenn die PID bei dir 0x2110 ist, dann passt das schon.

von funker (Gast)


Lesenswert?

Jörg, noch eine kurze Frage zum AVaRICE:

Ich habe versucht, die letzte Version mit MinGW für Windows zu 
kompilieren (ähnlich der Anleitung unter 
http://www.nongnu.org/avr-libc/user-manual/install_tools.html (Building 
and Installing under Linux, FreeBSD, and Others)), aber es geht nicht 
(u.a. make Fehler termios.h fehlt - wurde auch von configure erkannt, 
aber nicht als Fehler gemeldet). Nun gut, MinGW bietet ja auch keine 
volle POSIX-Unterstützung, aber wenn es schon in der Anleitung steht, 
dass es mit MinGW ginge, hätte ich jetzt mehr Erfolg erwartet.

1) Siehst Du überhaupt eine Chance, das ganze mit MinGW zu kompilieren?

Zur Not müsste ich wohl den Weg über Cygwin gehen, aber ich wollte mir 
das Mitführen der Cywin-DLL ersparen, daher habe ich alle anderen Tools 
bisher mit MinGW erstellt.

2) Ich sehe ohnehin gerade im Quellcode, dass selbst 2.13 keinen Support 
für JTAGICE3 hat. In deinem Trunk 2014-10-13 sehe ich aber diesen 
Support. Muss also den runterladen, aber der wird desselbe Problem 
bereiten...
Blöderweise kann ich hier kein SVN machen (sitze hinter einem Proxy, der 
das verbietet - selbst bei "svn checkout 
http://svn.code.sf.net/p/avarice/code/trunk avarice-code", wie im 
SorceForge-Link angegeben).

3) Ist es ein großer Aufwand, Unterstützung für neue Typen einzubauen 
(bspw. könnte ich mal versuchen, die ATmega256RFR2 zu beschreiben). I/O 
Register sind ja in ioreg.cc beschrieben, das würde ich hinkriegen, den 
Code dafür zu erstellen, aber damit wird es alleine nicht getan sein? In 
devdecr.cc und jtag.h sehe ich die Strukturen für die Beschreibung eines 
Devices, allerdings frage ich mich, wo ich alle die Informationen 
herkriegen soll (einen ATmegaRFR256, dessen ID ich über JTAG auslesen 
könnte, habe ich nicht).

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


Angehängte Dateien:

Lesenswert?

funker schrieb:

> Nun gut, MinGW bietet ja auch keine
> volle POSIX-Unterstützung, aber wenn es schon in der Anleitung steht,
> dass es mit MinGW ginge, hätte ich jetzt mehr Erfolg erwartet.

Steht doch nicht drin, sondern da steht:
1
Build the tools below in Cygwin.

AVaRICE ist ziemlich POSIX-lastig in der kompletten Implementierung,
daher geht das nur mit Cygwin.

> Zur Not müsste ich wohl den Weg über Cygwin gehen, aber ich wollte mir
> das Mitführen der Cywin-DLL ersparen, daher habe ich alle anderen Tools
> bisher mit MinGW erstellt.

Ich weiß, der Cygwin-DLL-Krams ist ätzend (und per selbst ernanntem
Ordnungshüter-Syndrom darf man das auch nicht statisch linken).

> 2) Ich sehe ohnehin gerade im Quellcode, dass selbst 2.13 keinen Support
> für JTAGICE3 hat. In deinem Trunk 2014-10-13 sehe ich aber diesen
> Support.

Stimmt.  Wird wohl höchste Zeit, da mal wieder einen Release
rauszuschieben.

> bereiten...
> Blöderweise kann ich hier kein SVN machen (sitze hinter einem Proxy, der
> das verbietet - selbst bei "svn checkout
> http://svn.code.sf.net/p/avarice/code/trunk avarice-code", wie im
> SorceForge-Link angegeben).

Ja, der Proxy müsste dafür die WebDAV-HTTP-Requests durchreichen.

Ich hänge dir mal einen aktuellen Snapshot an.  Der hat den
zusätzlichen Vorteil, dass da autoconf/automake schon gelaufen sind,
du hast also ein "configure" dabei.

> 3) Ist es ein großer Aufwand, Unterstützung für neue Typen einzubauen
> (bspw. könnte ich mal versuchen, die ATmega256RFR2 zu beschreiben).

ATmega256RFR2 ist schon dabei, das habe ich noch unter Atmel-Flagge
gemacht damals.

> I/O
> Register sind ja in ioreg.cc beschrieben, das würde ich hinkriegen, den
> Code dafür zu erstellen, aber damit wird es alleine nicht getan sein?

In tools/ gibt es noch ein bisschen XSLT dafür.  Geht nicht
ganz automatisch, aber vieles.  (tools/ ist aber kein Bestandteil
eines Releases, daher auch nicht im angehängten Archiv mit drin.)

von funker (Gast)


Lesenswert?

Jörg Wunsch schrieb:
> Steht doch nicht drin, sondern da steht:
> Build the tools below in Cygwin.

Ich meinte in der zitierten Anleitung "Building and Installing under 
Linux, FreeBSD, and Others", nicht in Deinen Readme-Dateien. Bei Deiner 
Readme steht das explizit drin, das stimmt, und dort habe ich es auch 
gelesen. Ich wundere mich aber, wieso es eine (andere) Anleitung im Netz 
gibt, die behauptet, es ginge mit MinGW, wenn das quasi ausgeschlossen 
ist. Aber egal.

Vielen herzlichen Dank für den Snapshot, da werde ich gleich mal mein 
Glück versuchen, es (mit Cygwin) zu kompilieren.

73

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


Lesenswert?

funker schrieb:
> Ich meinte in der zitierten Anleitung

Ja, genau aus der habe ich das zitiert. ;-)

von funker (Gast)


Lesenswert?

Jörg Wunsch schrieb:
> Ja, genau aus der habe ich das zitiert. ;-)

Tja, dann habe ich das überlesen. Mein Fehler...

Nun gut, avarice ist nun kompiliert (musste ja leider auch die libusb 
dann nochmal unter Cygwin kompilieren, und zwar nutze ich libusb-1.0.19 
mit libusb-compat0.1.5). Nach ein paar Schwierigkeiten mit Libusb und 
Cygwin-64 unter Win7 ging es dann.

Wie konnektiere ich denn nun meinen JTAGICE3 (was ist der devname)?

Ich bin mal ganz naiv rangegangen und habe gemäß manpage-Text "The  AVR 
Dragon and JTAGICE3 can only be connected through USB, so this option 
defaults to "usb" in that case"

avarice -3 -j usb :4242

oder auch

avarice --jtag usb --jtag3 :4242

eingegeben und erhalte
1
AVaRICE version 2.13svn20141210, Dec 11 2014 12:39:49
2
3
Defaulting JTAG bitrate to 250 kHz.
4
5
cannot read serial number "No such file or directory"

oder wenn ich --jtag3 bzw. -3 weglasse, lautet die Meldung "did not find 
any USB device".

AVRDUDE findet meinen JTAGICE3 aber:

I:\>avrdude -p m128rfa1 -c jtag3

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 
0.08s

avrdude: Device signature = 0xXXXXXX (ausge-ixt)

avrdude: safemode: Fuses OK (E:FE, H:99, L:62)

avrdude done.  Thank you.


Hast Du eine Idee? Kann meine 3.15er Firmware vielleicht in AVaRICE doch 
Probleme machen, trotz 0x2110 VID (USB\VID_03EB&PID_2110&REV_0100)?

Oder schieße ich mir ins Knie, weil ich unter Windows den fertigen 
libusb-win32-bin-1.2.6.0 benutzt habe, aber AVaRICE mit neuerer LibUSB 
kompiliert habe (sollte aber eigentlich kompatibel sein)? Ein Linken 
gegen die im fertigen Paket mitgelieferte Library schlug fehl, aber ggf. 
habe ich auch was falsch gemacht. Ich könnte AVARICE nochmal versuchen, 
gegen das "passende" Paket zu linken.

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


Lesenswert?

funker schrieb:

> avarice -3 -j usb :4242

Korrekt

> cannot read serial number "No such file or directory"

Klingt allerdings in der Tat irgendwie nach einem libusb-Problem.

Leider habe ich keine Ahnung, wie man sowas auf Windows debuggt.
Auf meinem FreeBSD würde ich da ktrace oder dtrace anwerfen …

> AVRDUDE findet meinen JTAGICE3 aber:
>
> I:\>avrdude -p m128rfa1 -c jtag3

Allerdings eben nicht unter Cygwin und daher mit anderer libusb
gebaut.

Hast du mal die libusb ausprobiert, die bei Cygwin verfügbar ist?

von funker (Gast)


Lesenswert?

Jörg Wunsch schrieb:
> Hast du mal die libusb ausprobiert, die bei Cygwin verfügbar ist?

Vorher nein, nur die selbst erstellte. Jetzt aber ja, das Ergebnis ist 
nun, dass die Meldung "did not find any USB device" nun auch bei 
"avarice -3 -j usb :4242" erscheint anstelle von "No such file or 
directory" (immerhin hat sich was getan). Die dritte Option, ein Linken 
gegen das libusb-win32-Paket funktioniert generell nicht (Compiler 
scheint mit der mitgelieferten libusb.a nichts anfangen zu können).

Übrigens habe ich meine JTAGICE-Firmware nun auf V 2.15 gebracht (mit 
dem Firmware-Tool von Atmel), ändert aber auch nichts.

Ich spekuliere jetzt mal ein wenig: Mit dem unter Cygwin mitgelieferten 
libusb wird eine cygusb0.dll benötigt (liegt auch vor und ist 
installiert). Ich rate jetzt einfach mal, dass der libusb0.sys-Treiber 
mit dieser DLL nicht zusammenarbeitet, genausowenig, wie wenn ich gegen 
aktuelle libusb linke. AVaRICE hat also enwteder statisch eine aktuelle 
libusb oder dynamisch die von Cygwin in Verwendung, je nachdem, wie ich 
kompiliere. AVRDUDE hingegen habe ich statisch gegen die libusb.a linken 
können, die im libusb-win-Paket enthalten war. Folglich kann AVRDUDE mit 
der passenden libusb mit dem Windows-Treiber kommunizieren, aber keine 
der Varianten von AVaRICE... Das bringt mich auf die Idee, mal exakt die 
Quellen zu nutzen, die von libusb-win32 verwendet wurden. Kann aber auch 
schief gehen...

Zum Verzweifeln. Jetzt habe ich schon einen aktuellen AVaRICE von Dir, 
bringe ihn aber nicht zum Laufen... Wird wohl nichts aus schönem 
debuggen, sehr schade...oder ich muss halt doch noch einen AVR Dragon 
kaufen.

Könnte man eigentlich auch mit einem FT2232 basierte JTAG-Dongle 
langfristig in AVaRICE einbinden oder fehlt dazu dann die Doku, wie 
Atmel nun eigentlich die über USB empfangenen Daten letzlich in 
JTAG-Signale umsetzt? Das ist ja einer der großen Vorteile von OpenOCD 
bei ARM, dass man mit 10 EUR-USB-Dongle auch debuggen kann...

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


Lesenswert?

funker schrieb:

> Zum Verzweifeln. Jetzt habe ich schon einen aktuellen AVaRICE von Dir,
> bringe ihn aber nicht zum Laufen... Wird wohl nichts aus schönem
> debuggen, sehr schade...oder ich muss halt doch noch einen AVR Dragon
> kaufen.

Vielleicht lässt du ja ein unixoides OS in einer VM arbeiten? ;-)

Sorry, ich auch gerade keine freien Valenzen, mir den ganzen
Cygwin-Kram irgendwo in einer VM anzutun.  Irgendwie muss das ja
aber mal alles funktioniert haben, sonst würde es ja auch mit einem
Dragon nicht klappen.

> Könnte man eigentlich auch mit einem FT2232 basierte JTAG-Dongle
> langfristig in AVaRICE einbinden oder fehlt dazu dann die Doku

So isses: die JTAG-Kommandos zum Debuggen hat Atmel nie dokumentiert.

Es gab mal ein paar halbherzige Ansätze zum reverse engineering,
aber meines Wissens ist nichts davon so weit getrieben worden, dass
man nun bei OpenOCD ein AVR-Debug-Backend daraus gebaut hätte.

von funker (Gast)


Lesenswert?

Jörg Wunsch schrieb:
> Sorry, ich auch gerade keine freien Valenzen,

Das verstehe ich, wie ich selbt feststellen muss, sind schnell mal ein 
paar Stunden weg, wenn man mal dies mal das ausprobiert.

Für die nächste Zeit belasse ich es also damit, dass es halt (noch) 
nicht mit Cygwin geht oder vielleicht auch wegen dem sehr aktuellen 
Cywin nicht geht oder weil ich einfach zu blöd dazu bin. Vlt. findet 
sich ja ein Fähiger, der das AVaRICE in seiner neuesten Version auch für 
JTAGICE3 unter Windoof zum Laufen kriegt...

Jedenfalls nochmal vielen Dank für den Support bis hier!

von funker211 (Gast)


Lesenswert?

SUCCESS! ERFOLG! HURRA!

Update zum Problem mit AVaRICE: Nun läuft es (unter Vorbehalt) auch mit 
JTAGICE3 unter Windows (mit Hilfe der Cygwin-DLL)!

Ich habe mir noch mal ein wenig Zeit genommen, alles genau 
durchzuchecken und nun einen Weg gefunden, der geht.

Mit der libusb.a aus dem SOURCE-Package, also libusb-win-src-1.2.6.0, 
ließ sich AVaRICE komplilieren UND läuft dann auch.

"Läuft dann auch" heißt dabei, dass JTAGICE3 erkannt wird und ich damit 
schon mal die Fuses lesen konnte (avarice -r -3). Debugging habe ich 
noch nicht probiert, aber dass das Fuses lesen nun geht und damit 
JTAGICE3 prinzipiell funktioniert ist doch schon mal was!!!

von Volker T. (funker211)


Lesenswert?

Jetzt logge ich mich doch mal noch ein, damit ich auch mitbekomme, wenn 
jemand interesse am fertig kompilierten Programm hat (avarice.exe). Wenn 
also jemand die AVaRICE version 2.13svn20141210 mit Support für JTAGICE3 
braucht, einfach bei mir melden...

von Sebastian W. (braindog)


Lesenswert?

Volker T. schrieb:
> Jetzt logge ich mich doch mal noch ein, damit ich auch mitbekomme, wenn
> jemand interesse am fertig kompilierten Programm hat (avarice.exe). Wenn
> also jemand die AVaRICE version 2.13svn20141210 mit Support für JTAGICE3
> braucht, einfach bei mir melden...

Hallo Volker,
Ich versuche auch gerade das Avarice aus Svn unter Cygwin 64Bit zum 
laufen zu bekommen, leider bisher erfolglos. Hierzu verwende ich derzeit 
das fertige libusb-win32 Binary zip. Es gelang mir bisher nicht mit den 
verschiedenen zur Verfügung stehenden gcc-varianten in cygwin entweder 
die libusb.a beim configure mit einzubinden oder das avarice 
durchzubauen. Mit welcher Konstallation hast du es geschafft? Ziel ist 
die Verwendung des JtagIce3 mit dem gdb unter Windows7 64Bit.
Gruß
Sebastian

von Volker (Gast)


Lesenswert?

Hallo Sebastian,

sorry für die späte Antwort. Meine komplette Liste (den ersten Teil hast 
Du ja schon erledigt, einfach ignorieren):

Vorbereitung:

- Cygwin installieren, nebst allen Tools zum Kompilieren. Die restlichen 
Schritte gehen davon aus, dass unter Cygwin gearbeitet wird!
- Hinweis: MikTeX muss schon installiert und der Pfad zum Executable auf 
der Pfadvariable sein. Ebenso /usr/local/bin und /bin.

libusb.a erstellen:

- libusb-win32-src-1.2.6.0 herunterladen: 
http://sourceforge.net/projects/libusb-win32/files/libusb-win32-releases/1.2.6.0/
- Nach $HOME entpacken
- cd $HOME/libusb-win32-src-1.2.6.0
-
1
make
 (make liefert Fehler, erstellt trotzdem libusb.a, bis dahin 
funktioniert das also, alles weitere brauchen wir nicht)

Weiter mit AVaRICE:

- AVaRICE herunterladen: http://avarice.sourceforge.net/
- AVaRICE nach $HOME entpacken
- cd $HOME/avarice-2.13
- mkdir build
- cd build
- Wir sind nun also in $HOME/avarice-2.13/build. Hier heraus rufen wir 
configure auf. Configure benötigt den Pfad und die Angabe der 
USB-Libraries und zur Header-Datei lusb0_usb.h:
-
1
../configure LDFLAGS="-static -L$HOME/libusb-win32-src-1.2.6.0" LIBS="-lusb" CFLAGS="-I$HOME/libusb-win32-src-1.2.6.0/src" CPPFLAGS="-I$HOME/libusb-win32-src-1.2.6.0/src" 2>&1 | tee avarice-configure.log
-
1
make LDFLAGS="-static -L$HOME/libusb-win32-src-1.2.6.0" LIBS="-lbfd -liberty -lintl –liconv –lusb" CFLAGS="-I$HOME/libusb-win32-src-1.2.6.0/src" CPPFLAGS="-I$HOME/libusb-win32-src-1.2.6.0/src" 2>&1 | tee avarice-make.log
-
1
make install 2>&1 | tee avarice-make-install.log

Abschlussarbeiten:

- Mit "cygcheck /usr/local/bin/avarice.exe" kann man testen, welche DLL 
man zur Ausführung von avarice.exe braucht. Hat man mit LIBS=‘…‘ sein 
make durchgeführt, so wird außer der Cywin1.dll nichts weiter gebraucht.

Hinweis: Eine ggf. unter /usr/local/include stehende usb.h-Datei kann zu 
Konflikten führen, diese ggf. temporär umbenennen. Das habe ich 
vorsichtshalber gemacht (denn ich hatte zunächst den Weg mit erstellen 
von libusb-1.0 und libsub-compat-0.x versucht und dort dann die 
entsprechenden Dateien), ob's wirklich nötig ist, habe ich aber nicht 
geprüft.

Einfacher Test (lesen der Fuses über JTAGICE3):
1
avarice -r -3

Wenn das klappt, funktioniert AVaRICE prinzipiell.

von Volker (Gast)


Lesenswert?

Also der Knackpunkt war, nicht das Binary Package 
libusb-win32-bin-1.2.6.0 zu nutzen, sodnern das Source Package 
libusb-win32-1.2.6.0 und aus den dortigen Quellen dann libusb.a unter 
Cygwin64 für den eigenen Windows-7-Rechner zu erstellen.

Alle anderen Wege scheiterten bei mir (Verwendung des Binary Package 
libusb-win32-bin-1.2.6.0, Verwendung von libusb-1.0 und 
libusb-compat-0.x, Verwendung von fertigen libusb-Libraries unter Cygwin 
oder MinGW, Verwendung des letzten "echten" libusb-0.1.12).

von Volker (Gast)


Lesenswert?

Volker schrieb:
> Also der Knackpunkt war, nicht das Binary Package
> libusb-win32-bin-1.2.6.0 zu nutzen, sodnern das Source Package
> libusb-win32-1.2.6.0 und aus den dortigen Quellen dann libusb.a unter
> Cygwin64 für den eigenen Windows-7-Rechner zu erstellen.
>
> Alle anderen Wege scheiterten bei mir (Verwendung des Binary Package
> libusb-win32-bin-1.2.6.0, Verwendung von libusb-1.0 und
> libusb-compat-0.x, Verwendung von fertigen libusb-Libraries unter Cygwin
> oder MinGW, Verwendung des letzten "echten" libusb-0.1.12).

Ich meine:
...sondern das Source Package libusb-win32-src-1.2.6.0...

Und ferner:

Mein oben in der ersten Antwort hart eingegebener Pfad 
$HOME/avarice-2.13 ist natürlich zu ersetzen mit dem jeweils tatsächlich 
gültigen, der ja von der Version abhängt...

von Sebastian W. (braindog)


Lesenswert?

Hallo Volker,
vielen Dank für deine ausführliche Anleitung.
Gestern habe ich es, auf etwas anderen Wege, auch geschafft.

Sorry, ich hätte das schon gestern abend schreiben sollen.
Im nächsten Thread möchte ich kurz meinen Weg für die Nachwelt 
zusammenfassen.

Gruß

von Sebastian W. (braindog)


Lesenswert?

Hallo Volker, Liebe weitere Leser.

Ich wechsele den thread da das Topic nicht mehr zum aktuell besprochenen 
Thema passt. Ich hoffe das ist Ok und findet sich einfacher.

> Im nächsten Thread möchte ich kurz meinen Weg für die Nachwelt
> zusammenfassen.

Meine Zusammenfassung habe ich hier gepostet: 
Beitrag "Avarice für Atmel AVR JTAGICE3 unter Cygwin(64Bit) bauen"

Gruß
Sebastian

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.