Archiv verlassen und diese Seite im Standarddesign anzeigen : AVR: Im Bootloader eine Funktion an eine bestimmte Position setzen
Hallo,
ich programmiere derzeit einen Bootloader für einen AT90CAN64. Dieser funktioniert einwandfrei. Ich habe 64 kB Flash-Speicher und die Bootloader-Fuse-Bits auf 0x7000 gesetzt. In den Linker-Options habe ich folgendes hinzugefügt: -Ttext=E000
Dadurch landet der Bootloader an der korrekten Adresse im Flash und es läuft auch alles einwandfrei.
Jetzt kommt allerdings ein Zusatz: Ich muss auch vom Haupt-Programm ebenfalls in den Flash-Speicher schreiben können. Da dieser Code nur von der Bootsector-Section aus ausgeführt werden kann, muss die entsprechende Funktion also in den Bootloader. Diese hätte ich dann gerne an eine fixe Adresse, damit ich die Funktion auch sicher anspringen kann.
Dazu habe ich mir in den Memory-Einstellungen des Bootloader-Projekts eine Section (.bootloader_end) an die Adresse 0x7F80 hinzugefügt und die Funktion, die vom Hauptprogramm aufgerufen werden soll wie folgt deklariert:
#define BOOTLOADER_END_SECTION __attribute__ ((section (".bootloader_end")))
void write_flash (U16* ptrData, U32 destination, U32 size) BOOTLOADER_END_SECTION;
Leider meckert jetzt der Linker:
../avr/bin/ld.exe: section .bootloader_end loaded at [0000f418,0000f499] overlaps section .data loaded at [0000f418,0000f49f]
Kann mir jemand einen Tipp geben, wie ich das gelöst bekomme?
Viele Grüße,
Andreas
Dass du vom Hauptprogramm aus den NVM Controller nicht ansprechen darfst ist so nicht korrekt, aber die Flash Sektion des Hauptprogrammspeicher arbeitet dann nicht mehr!
Du kannst also getrost deine Calls vom Hauptprogramm aus ausführen, musst aber mit den paar mS Pause leben!
Wenn du jetzt nur die Methode aufrufen willst, wird dein Execution Pointer zwar in den Boot-Bereich springen, aber sobald der return kommt hängt dein Programm ebenfalls wieder.
Aber zu deinem Problem, ich glaube du musst ein "extern" der Methodendeklaration voranstellen, da er sonst versucht eine neue, leere Methode an der Adresse zu erstellen, während du mit extern explizit einen Verweis auf eine existierende Funktion erzwingst.
Ich bin mir da aber im Moment auch nciht sicher, an einem Bootloader habe ich vor 3 Jahren das letzte mal rumgeschraubt (unter anderem wollte ich das gleiche erreichen, mein Programm während einer Flash Write operation zu nutzen, musste dann aber einsehen dass ich den Programmkern in den Bootbereich hätte verschieben müssen um das zu realisieren)
Hallo Ceos,
vielen Dank für den Hinweis mit dem Schreiben. Ich würde es trotzdem gerne zunächst so versuchen, wie ich es im Eingangspost erklärt habe.
Die Funktion "write_flash" ist natürlich im C-Code des Bootloaders enthalten. Das Extern-Attribut muss ich dann im Hauptprogramm setzen. Die Fehlermeldung kommt aber beim compilieren des Bootloaders, wenn ich Versuche die Funktion an diese Adresse zu positionieren.
Viele Grüße,
Andreas
Oh okay das hab ich dann falsch gelesen
ich bin wegen 2erlei sachen verwirrt, zum einen warum du die methode an die adresse .bootloader_end statt .bootloader schreibst, vll. ist dein Problem dass du den falschen Marker benutzt und ich vermisse aus der Doku gelesen dass du der sektion eine startadresse gibst, du legst zwar fest wo .text anfängt aber nicht wo .bootloader liegen soll
https://www.microchip.com/webdoc/AVRLibcReferenceManual/FAQ_1faq_reloc_code.html
Da ich einen Bootloader programmiere, gibt es die Sektion .bootloader streng genommen nicht. Und selbst wenn befindet sich ja dort der Bootloader. Der Linker würde die Funktion dann wieder platzieren, wo er möchte. Ich möchte Sie aber an einer definierten Stelle im Flash haben. Deshalb lege ich eine neue Sektion an, in der nur diese Funktion kommt. Dann kann ich Sie vom Hauptprogramm direkt anspringen.
Es würde auch nichts nutzen den Code des Bootloaders in die Sektion ".bootloader" zu platzieren, da ich auch Interrupts benötige. Die IRQ-Tabelle kann meines wissens nach nur mit dem Trick der Text-Sektion (-Ttext=E000) am Start des Bootloader-Bereichs platziert werden.
das ist teilweise korrekt, um die ISR zu verschieben geht das nur so, aber da du eine sektion erzeugt hast, musst du sie auch an eine stelle schieben an der sonst nichts anderes ist, wie es in dem verlinkten Artikel beschrieben ist. Deine Sektion überlappt sich weil er scheinbar denkt dass der Teil der Methode ebenfalls im .data deklariert wird ... vielleicht fehlt irgend ein pragma oder ein zeichen dass die deklarierte Methode nicht ebenfalls teil von .data ist!?
Ich habe damals ein Template mit definierten Sektionen genutzt udn damit gearbeitet um mir diesen horror mit dem segmentieren meines codes zu ersparen
Jetzt hast du mein Problem genau verstanden. Dafür suche ich eine Lösung. Mein Wissen über die Compilter-Schalter, Pragma, etc. reicht nicht aus.
Ich vermute, die Sektion .data muss verschoben werden. Ich weiß aber nicht wie und habe auch mithilfe von Google keine Lösung gefunden. Es könnte aber auch sein, dass mein Lösungsansatz falsch ist und man die Funktion anders platzieren muss.
ich lgaube mit dem verschieben der .text als kniff um sich das explizite deklarieren pro methode zu ersparen kollidiert mit dem vorhaben bestimmte methoden an einer definierten adresse zu halten
ich schau mal ob ich das tempplate von damals noch irgendwo gespeichert habe, dann sparst du dir den kniff und hast volle kontrolle und keine kollisionen
okay ich habe gerade nochmal ein paar kleinere foreneinträge durchstöbert ... wenn du deine .bootloader_end sektion auch definierst (ähnlich wie mit der .text) sollte er theoretisch meckern dass deine sektion zu wenig platz hat um den code zu fassen, daraufhin musst du deine .bootloader_end einfach ein wenig verschieben bis es wieder klappt ... ich bin mir nicht sicher aber der begriff bootloader_end könnte möglicherweise schon vergeben sein und du solltest einen weniger "allgemeinen" namen für die sektion wählen, vll. bringst du den linker damit durcheinander
du könntest dir mal die map datei ansehen um zu prüfen wo deine methode gelinkt ist und welche bereiche sich dabei überschneiden (sofern er überhaupt dazu kommt eine map file anzulegen)
Ein anderer Namen der Sektion bringt keine Änderung. Selbstverständlich ist diese auch definiert, ansonsten würde es eine andere Fehlermeldung geben. Und Sie ist passend platziert. Es wird ja nicht bemängelt, dass Sie nicht reinpasst, sondern dass Sie überlappt. Ich habe es auch mit einem Projekt ohne Bootloader versucht. Hier funktioniert die PLatzierung und ich kann dort ich in der Hex-Datei sehen, dass die Funktion exakt an dieser Stelle platziert ist, und auch dass Sie 74 Bytes im Flash benötigt. Wie Eingangs geschrieben, ist die definierte Adresse der Sektion 7F80 = 0xFF00. Das bedeutet, ich habe in in der Section 256 Bytes Platz. --> Ausreichend.
Hier ein Auszug aus der map-datei:
.bootloader_end
0x0000f418 0x82
.bootloader_end
0x0000f418 0x82 CAN_bootloader.o
0x0000f418 write_flash
Da scheint was nicht zu passen. Warum bin ich aber überfragt.
- - - Aktualisiert - - -
Kommando zurück! Der Name der Sektion war tatsächlich die Ursache. Ich habe beim testweisen ändern nicht bemerkt, dass sich die Fehlermeldung ändert. Es war nämlich noch ein weiterer Fehler im Code. Mit einem anderen Namen für die Sektion funktioniert es nun. Vielen Dank!
als kleiner tipp, wenn du eine zentrale statemachine und passende miniatur subroutinen hast die einfach nur das gerät "am leben halten" kannst du sie aus dem hauptprogamm in den bootloader verschieben, sodass dein gerät nicht hirntot scheint während es sich selber umflasht
um dabei zusätzliche zustände oder funktionen im normalbetrieb bereitstellen zu können habe cih mich damals einer handgestrickten sprungtabelle bedient die cih beim starten in den RAM gelegt habe
die statemachine ist quasi nichts weiter als ein verschachtelter switch case der auf adressen im RAM zugreift um je anch state die notwendigen funktionen auszuführen, sofern sie im boot bereich liegen oder alternativ eine "verweigerung" oder "busy" zurück zu geben wenn ich gleichzeitig im NVM arbeite und eine aktion aus dem hauptprogramm angefordert wird
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.