Hallo und schöne Grüße ans Forum,
ich folgendes Problem:
ich möchte ein Crossworks-Projekt (STM32, *.hzp), was auf System A
(WinXP, Crossworks 2.2) problemlos funktioniert, auf System B (Win10,
Crossworks 2.35) kompilieren und debuggen, da ich nur noch kurzzeitig
zugriff auf System A habe. Ich habe sämtliche Dateien kopiert und auf
System B das Projekt geöffnet. Nun erhalte ich beim Build auf System B
folgende Fehlermeldung:
...
Linking UW005_Rudersteller_Version03.elf
THUMB Flash Release/thumb_crt0.o: In function `__putchar':
(.init+0xbc): undefined reference to `__stack_process_end__'
THUMB Flash Release/thumb_crt0.o: In function `__putchar':
(.init+0xc0): undefined reference to `__stack_process_start__'
Build failed
...
Irgendwie scheint der Linker (kompilieren klappt also) irgendwelche
Probleme zu haben, die abhängig sind vom System bzw. den
unterschiedlichen Versionen von Crossworks. Nur habe ich leider keine
Idee, wie ich den Fehler beheben soll. Ihr vielleicht?
_stack_process_end__ und __stack_process_start_ sind Linker Symbole aus deinem Linker File. Hast du das Linker File mit kopiert und benutzt das richtige im Projekt?
Hallo,
das Linker-File (ich vermute *.ld?) habe ich mit kopiert. Es befindet
sich in dem Ordner, in dem Crossworks die ganzen *.o -Files und auch das
hex-file (wenn es denn klappt) schreibt ("THUMB Flash Debug").
Habe auch gerade nochmal ein Clean probiert (*.ld, *.o, *.hex) wurden dabei gelöscht. Leider kam nach dem neuen Build wieder der gleiche Linker-Fehler.
>>...Richtiges Projekt...?
ich vermute schon, das, das ich kopiert habe, habe ich in Crossworks
geöffnet. Die Dateien usw. passen auch. Oder habe ich die Frage falsch
verstanden?
Neue Info: ich habe die Datei "thumb_crt0.s" aus dem Hauptordner von CrossWorks ebenfalls ausgetauscht. Also auf System B (Crossworks 2.35) arbeitet nun die "thumb_crt0.s" von System A (Crossworks 2.2) -> das Kompilieren und Linken klappt nun. Ein Vergleich der hex-Files zwischen dem auf System A erstellten Hex-File und dem nun auf System B erstellen Hex-File zeigt jedoch sehr viele Abweichungen, was ich mir nicht erklären kann. Abgesehen davon gefällt mir diese "Lösung" nicht sehr gut, da ich gerne wüsste, was ich durch den Austausch der Dateien ausgelöst habe. Ich werde dennoch dieses neue Hexfile mal flashen und schauen, ob das Programm funktioniert. Andere Lösungsvorschläge sind mir sehr willkommen. Schöne Grüße...
Habe nun CrossStudio 2.2 auf System B installiert (trial). Somit laufen auf beiden Systemen die gleichen IDE-Versionen. Kompilieren und linken des Projekts fehlerfrei, aber immer noch viele Abweichungen zwischen den erstellten Hex-Files auf beiden Systemen, egal ob Debug oder Release. Wie kann das sein? Ich bin bis jetzt davon ausgegangen, das sämtliche Einstellungen (Compiler, Optimierung, etc.), die für ein derartige Verhalten verantwortlich sein könnten, durch die Verwendung der gleichen Projektdatei (*.hzp) identisch sind. Oder gibt es noch andere Dateien, in denen irgendwelche Einstellungen gespeichert sind, die hierfür verantwortlich sein können? Danke.
Die Installation von "CrossStudio 2.2" nutzt sicher auch nicht irgendwelche bereits installierten Teile der neueren Version? In den Hexfiles kann auch buildzeitabhängiger Krempel drinstehen, oder auch Debuginfos (Pfade o.ä.) -- vergleich mal die Mapfiles.
Hallo Rufus, >> irgendwelche bereits installierten Teile der neueren Version? Wie kann ich das ausschließen? 2.35 deinstallieren oder kennst Du einen besseren Weg? >> In den Hexfiles kann auch buildzeitabhängiger Krempel drinstehen Eher nicht, der Vergleich zweier HexFiles von Sys A (Build an unterschiedliche Tagen) zeigt keine Unterschiede. >> Mapfiles OK, ich vermute wir kommen der Sache näher, die *.map Dateien sind unterschiedlich (Build Release auf Sys A und Sys B)
Henning schrieb: > Wie kann ich das ausschließen? 2.35 deinstallieren Du könntest das Verzeichnis, in dem 2.35 installiert ist, testweise umbenennen. Allerdings müsstest Du auch suchen, ob möglicherweise irgendwelche Komponenten außerhalb dieses Verzeichnisses installiert sind, d.h. unter %appdata% (zum jeweiligen Benutzer gehörend) oder unter %programdata% (systemweit). Es ist schon zu lange her, daß ich mal was mit CrossWorks gemacht habe, und das war obendrein für den msp430 ...
Hallo, ich habe nun Crossworks 2.35 von System B deinstalliert, %appdata% von allen Crossworks-Dateien befreit und Crossworks 2.2 nochmal neu installiert. Hat leider nicht zum Ziel geführt, das Problem besteht weiterhin. Die *.map und *.hex Dateien sind weiterhin unterschiedlich zwischen System A & B. Wie wird das map-File eigentlich generiert?
Ich kenne zwar Crossworks nicht, aber, gibt es da keine Möglichkeit Projekte geordnet zu Ex- und Importieren?
Henning schrieb: > Die *.map und *.hex Dateien sind weiterhin unterschiedlich zwischen > System A & B. Die Map-Datei ist eine Textdatei; worin bestehen denn die Unterschiede? Werden Symbole an komplett andere Adressen gelegt?
Ist es vielleicht so, dass die jeweiligen Versionen auch unterschiedliche Compiler und Linker verwenden? Da wär es es dann eher unwahrscheinlich, dass das gleiche image raus kommt !!! kein Ast(Zweig)
Zweig schrieb: > ist es vielleicht so, dass die jeweiligen Versionen ... Es sind zweimal die gleichen Versionen.
Danke für die vielen Hinweise, ich komme aber erst Montag oder Dienstag wieder dazu, diese zu bearbeiten. Bis dahin schöne Grüße und nochmals Danke für die Hilfe.
Hast du auf beiden die gleichen support packages (Tools - Show Installed Packages) installiert? Also gleiche Versionen für Prozessor und CMSIS? Irgendwie hab ich im Hinterkopf, dass ich so ein Problem auch schon mal hatte. Aber mir will nicht einfallen, wie ich es gelöst habe. Oops, gerade nachgesehen im Header meiner thumb-crt0.s ************************************************************************ ***** * * 2011xxxx added _STACK_START/_STACK_END definition * 20130925 merged changes in CrossWorks 2.3 * ************************************************************************ ***** Diese zwei globalen Variablen brauchte ich aber nur, weil ich zur Laufzeit den Stack checken wollte. Deine zwei fehlenden _stack_process_xxx_ sind nach wie vor in MEINER thumb-crt0.s welche aber offensichtlich nicht mehr die ist welche original mitgeliefert wurde. Es sieht für mich jetzt so aus, dass in neueren thumb-crt0.s diese Symbole nicht mehr vorhanden sind, du aber ein nicht dazu passendes putchar verwendest. Wo ist putchar definiert (siehe .map file)? Ich würde mal deine zwei thumb-crt0.s vergleichen und dann die putchars suchen.
Hallo, Danke für die Info Andi. Ich muss jetzt aber für ca. 2 Wochen auf Dienstreise, da kann ich mich mal darum kümmern. Kann mich aber erst melden, wenn ich zurück bin. Bis dann.
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.