Hallo Leute, ich programmiere gerade an einem custom bootloader für einen STM32F105RC. Das Update funktioniert über usb und läuft bereits einwandfrei. Nun habe ich das Problem das es mehrere Programme gibt. Nun möchte ich eine Art Modellnummer in das bin file einfügen. Das heißt beim ersten mal aufspielen durchsuche ich den Stick auf verfügbare Files und in einem Menü kann man anschließend die benötigte software auswählen. Bei einem Update soll dann nur mehr für das model (wird im eeprom gespeichert) die Software aufgespielt werden. Meine frage wie kann ich das bin file abändern ohne das anschließend fehler auftreten. Ich habe schon mal wo gelesen das man in der vector table nicht verwendete interrupts überschreiben kann. Dazu habe ich aber nichts genaueres gefunden. Ich benötige mindestens 10 byte die immer an der selben Adresse stehen müssen. Vielen Dank im Voraus!
Ich würde nicht das .bin File ändern, sondern das direkt im Quellcode machen. Z.B. mit einer Sektion am Ende oder an einer definierten Speicheradresse. Kleiner Nachteil, wenn die Kennung ganz hinten im .bin hängt: Du musst immer das ganze Flash programmieren, auch wenn es ggf. nur ein Mini-Programm ist. Das kann die Programmierdauer vervielfachen. Ggf. kannst Du auch eine Kennung einfügen, die garnicht mitprogrammiert wird, sondern nur von der PC-Software ausgewertet und nicht zum Bootloader geschickt wird. Gruß, Stefan
franz schrieb: > Ich habe schon mal wo gelesen das man in der vector > table nicht verwendete interrupts überschreiben kann. Dazu habe ich aber > nichts genaueres gefunden. Wenn man die als Reserved markierten mit 0 gesetzten Vectoren überschreiben darf, dann ist es vermutlich am Leichtesten das in der startup_stm32f105xc.s zu tun. Im schlimmsten Fall springt er in irgend einen Error Handler. Versuch macht kluch.
Im Programm eine globale Variable mit der Kennung anlegen, used falls du die IDs sonst nirgends verwendest, damit nichts wegoptimiert wird.
1 | const t_HwInfo m_oHwInfo __attribute__ ((section(".hardwareinfo"), used))= {BOARD_VERSION, MTU_CHIP_ID, BOARD_ID, BOARD_BOOTLOADER_CRC}; |
Und die Section .hardwareinfo musst du noch im Linkerscript eintragen, dann liegt m_oHwInfo da drinnen. So ca:
1 | .hardwareinfo (0x10c) : |
2 | {
|
3 | KEEP(*(hardwareinfo hardwareinfo.*)) |
4 | } > FLASH |
Aber da gibt es verchiedene Varianten, hier liegt die struct dann bei 0x10c, das darf sich natürlich nicht mit anderen Dingen überschneiden, wie zB den IRQ Vektoren die auch am Beginn stehen.
Hab gerade meinen F030 einen Wert in seine Vectortabelle geschrieben, das Prog läuft wie gewohnt und der Eintrag ist auch im .hex file zu sehen. Scheint also zu funktionieren einfach 4 Bytes an Stelle einer 0 in die Vectortabelle in die startup_... zu schreiben. Zu mindest beim F030.
Danke für die schnelle info. Ich werde mich mal über die Vectortable noch mehr herausfinden bzw. einfach mal ausprobieren ob ich nicht in einen fault handler lande. Stefan schrieb: > Ggf. kannst Du auch eine Kennung einfügen, die garnicht mitprogrammiert > wird, sondern nur von der PC-Software ausgewertet und nicht zum > Bootloader geschickt wird. Das bin file wird direkt über einen USB Stick aufgespielt (kein PC zum programmieren notwendig) @Thomas: dein vorschlag gefällt mir derzeit am besten werde ich auch ausprobieren. Gilt nur herauszufinden auf welche addresse ich die Info hinschreiben darf. Auf jeden Fall dake für eure schnelle hilfe!
franz schrieb: > Das bin file wird direkt über einen USB Stick aufgespielt (kein PC zum > programmieren notwendig) Aber irgendwie muss es ja auch auf den USB Stick kommen. So wie sich das anhört, ändert sich die Information am USB Stick nicht im Studentakt, sondern das klingt eher nach einem USB-Stick mit dem ein Service-Techniker rausfährt und Geräte updated, bis nach einem halben Jahr eine neue Firmwareversion verfügbar ist. In diesem Fall würde ich für das BIN-File selbst einen Container bauen, mit einer anderen Dateiendung, in dem zb in den ersten 20 oder 30 Bytes die Information steht, die dein Menüsystem braucht. Wird eines davon ausgewählt, dann werden diese 20 Bytes übersprungen und der Inhalt des originalen BIN-Files bleibt wieder übrig und wird geflasht. Derjenige, der den INhalt des USB Sticks zusammenstellt bzw. updated, hat ein Tool, dem er das BIN-File von der Toolchain zeigt, sowie die Menüinformation vorgibt, und das dann genau diese Containerdatei erstellt.
@karl heinz: Genau so ist es und danke jetzt verstehe ich auch was du meinst. Diese Idee gefällt mir auch sehr gut. Jetzt habe ich die Qual der Wahl :D Der Punkt mit der Vectortable funktioniert auf die schnelle ganz gut. Jedoch wird das File abgeändert, was ich einfach nicht schön finde. Ich denke Karl heinz deine Idee hat gewonnen weil sie am einfachsten ist.
franz schrieb: > Ich denke Karl heinz deine Idee hat gewonnen weil sie am einfachsten > ist. Am einfachsten ist sie nicht. Aber ich habe auch eine Abneigung dagegen, ein von einem Compiler erstelltes Executable an nicht dezidierten Stellen zu verändern (Vektortabelle). Vielleicht passiert es auch nie aber mglw. wird irgendwann genau dieser Vektor benutzt und dann erinnert sich kein Mensch mehr daran, dass da eine Zweckentfremdung stattfand.
Zur info: Ich habe jetzt die Idee von Karl Heinz umgesetzt und sie funktioniert einwandfrei. Dadurch kann ich einfach und ohne Begrenzung information zur Applikation für den Bootloader anfügen. Beim Update selbst wird dieser Bereich einfach übersprungen! Danke an alle für Eure Vorschläge!!!
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.