Hallo Zusammen, Wir verwenden einen ATXMega und möchten von der Applikation aus in den FLASH Speicher schreiben können. Dazu müssen sich die Funktionen zum schreiben in der Sektion des Bootloaders befinden. Nun soll in der Bootloader Sektion auch ein Bootloader installiert werden, welcher die gleichen Funktionen verwendet. Damit die Funktionen vom Bootloader wie auch von der Applikation verwendet werden können, suche ich eine Lösung. Diese Lösung soll auch dann noch funktionieren, wenn der Bootloader oder die Applikation irgend wann mal mit einer anderen GCC Version übersetzt wird. Mir schwebt vor, ein drittes Projekt mit nur diesen Funktionen zu erstellen und eine Lib zu erzeugen. Diese Lib wird an einem bestimmten Ort im FLASH abgelegt (durch ändern der .text section). Diese Lib wird danach zum Bootloaders und zu der Applikation hinzu gelinkt. Wie kann man nun dem Linker mitteilen, dass er nur die Adressen der Funktionen verwenden soll und nicht den Code in der Lib? Die Funktionen benötigen keinen globalen Speicher. Was für andere Möglichkeiten gibt es, ohne die Funktionszeiger von Hand zuweisen zu müssen? Gruss
hmmm Die Funktion foo in eine eigene Section .foo legen und zum Bootloader hinzulinken. Dazu muss wahrscheinlich .bootloader im Linkerscript kleiner gemacht werden, damit auch .foo in den Bootloader-Bereich zu liegen kommt. .foo wird per Skript oder --section-start platziert. Die Anwendung wird nicht gegen foo.o gelinkt (dann würde die Anwendung denn Bootloader überdecken), sondern am einfachsten Symbol foo per --def-sym auf den bekannten Wert definiert. Das ist ne GCC/binutils Standard-Methoden und funktioniertauch mit anderen Ausprägungen von GCC/binutils (Version, Plattform, Target, ...) Einfacher ist vielleicht die Moglichkeit, daß der Bootloader den Wert des Symbols (also die Adresse von foo) an eine bekannte Stelle im Flash schreibt -- zB and Ende -- und die Anwendung den Wert verwendet. Nachteil ist, daß foo nur indirekt erreichbar ist, aber der Mechanismus ist einfacher: kein anderes ld-Skript, etc.
Was geht (wurde hier auch schon ein paarmal diskutiert) ist: Den Bootloader mit der Anwendung linken, beide beim "Erstbeschreiben" gemeinsam flashen. Durch das Zusammenlinken kann die Anwendung beliebig Bootloader-Funktionen nutzen. Das Hex-File zum späteren Update über Bootloader wird genauso gelinkt, nur entweder vor dem Upload den Bootloader-Teil abschneiden, darauf vertrauen, dass der Bootloader sich eh nicht selber überschreibt, oder dem Bootloader einfach beibringen, diesen Teil zu ignorieren. Wichtig dabei: den Bootloader-Teil wirklich nur dazulinken, nicht jedes mal neu Compilieren. Sonst geht das ganze bei ner neueren gcc-Version oder anderen Compiler-Optionen schnell schief.
Vielen Dank für eure Vorschläge. Ich habe alle gemeinsamen Funktionen in einer .section zugewisen und daraus ein .o File erzeugt. Diese .o File wird vom Bootloader Projekt erzeugt und da auch verwendte. Im Projekt der Applikation lege ich diese .section an die gleiche Stelle, wie im Bootloader und linke das .o File hinzu. Muss nur noch das HEX File bearbeiten, dass die Funktionen nicht geladen werden.
Was auch funktioniert: - Bootloader als eigenständige Anwendung - Adressen der von Anwendung und Bootloader verwendeten Funktionen in einem Array ablegen (Array of Function-Pointers). - Dem Array mittels Attribut eine input-section zuweisen - Im Linkerscript des Bootloaders diese input-section einer output-section an bekannter Adresse zuweisen (z.B. direkt hinter der nach "remapping" verwendeten Interruptvektortabelle des Bootloaders) - In der Anwendung diese bekannte Adresse des Arrays und die ebenfalls bekannte Reihenfolge der Funktionen für Funktionspointer verwenden. Spart Basteln mit hex-Dateien. Bei Aktualsierungen darf nur nicht die Adresse und Reihenfolge innerhalbs des Arrays verändert werden. Wichtig ist noch, dass die gemeinsam verwendeten Funktionen keine statischen Variablen enthalten, um Überschneidungen im RAM auszuschliessen. Kann anhand des map-Files des Bootloaders überprüft werden. Darauf achten, dass die Adressen für die Funktionspointer aus dem Programmspeicher zu lesen sind.
Noch zur Information: objcopy bietet die Option "--remove-section", somit kann verhindert werden, dass gewisse Sektionen im HEX File abgelegt werden.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.