Hallo! Ich würde gerne eine FW-Update Funktion realisieren. Das ich das mit IAP machen muss habe ich schon rausgefunden. Nur das zu verwendende Dateiformat ist mir noch nicht klar. Nimmt man besser das bin-file, oder hex-file? Danke & Grüße Sven
Ich hab mir jetzt schon bestimmt 10 verschiedene Bootloader geschrieben, von IAP hab ich aber noch nix gehört. Hab bis jetzt immer mit Intels hex format gearbeitet. Hat den Vorteil einer eingebauten und gut dokumentierten Integritätsprüfung.
Sven K. schrieb: > Nimmt man besser das bin-file, oder hex-file? Ein BIN-File ist eigentlich nur sinnvoll, wenn: 1. alles am Stück ist (trifft bei einem Bootloader wohl zu) 2. Die Daten in sich abgesichert sind, z.B. mit einer Checksumme (sollte bei einem Bootloader zutreffen) Zu IAP fällt nicht mal Google was passendes ein, soll das vielleicht IAR heissen? Georg
IAP steht soweit ich weiss für In-Application Programming. Und das hat erstmal noch nichts mit einem Dateiformat zu tun. Der µC muss irgendwie die Programmierdaten übermittelt bekommen über eine irgendeine Schnittstelle wie UART, SPI, CAN oder andere. Und die Daten können wiederum aus einer Datei gelesen werden dessen Format auch völlig unabhängig vom IAP ist.
Sven K. schrieb: > Ich würde gerne eine FW-Update Funktion realisieren. > Das ich das mit IAP machen muss habe ich schon rausgefunden. > Nur das zu verwendende Dateiformat ist mir noch nicht klar. > Nimmt man besser das bin-file, oder hex-file? Das ist eher zweitrangig. Was hingegen weitaus wichtiger ist, ist die Gestaltung deiner eigentlichen Firmware. Einen Teil mußt du resident machen, d.h. daß er NIEMALS geändert oder überschrieben werden soll. Und dieser Teil muß auch dann noch funktionieren, wenn bei einem FW-Update etwas schief gelaufen ist. Eben damit man das Gerät nicht "gebrickt", also unbrauchbar gemacht hat, sondern damit man das Update wiederholen oder das Wieder-Aufspielen des Originals tun kann. Deshalb muß dieser Teil auch durch irgendwas (gedrückte Taste, gesteckter Jumper o.ä.) am Systemstart erreichbar sein - könnte ja sein, daß das Update zwar gelaufen ist, aber die neue FW Mist ist. Ansonsten hast du beim übertragenen Format (sowas willst du ja sicherlich über irgend eine Strippe tun, also seriell oder USB oder so) die freie Wahl. Ich habe sowas bei meinen Geräten blockweise gemacht, die Blöcke so groß, daß sie bequem neben dem lademodul ins RAM passen. Selbige dann versehen mit: Adreßangabe, Blocklänge, Adler32. Das reicht eigentlich. W.S.
ui schrieb: > Ich hab mir jetzt schon bestimmt 10 verschiedene Bootloader geschrieben, > von IAP hab ich aber noch nix gehört. Hi! Klingt interessant! Auch für einen STM32? ui schrieb: > Hab bis jetzt immer mit Intels hex format gearbeitet. Hat den Vorteil > einer eingebauten und gut dokumentierten Integritätsprüfung. Also ist hex zu bevorzugen? Georg schrieb: > 1. alles am Stück ist (trifft bei einem Bootloader wohl zu) > 2. Die Daten in sich abgesichert sind, z.B. mit einer Checksumme (sollte > bei einem Bootloader zutreffen) Zweimal Ja. Georg schrieb: > Zu IAP fällt nicht mal Google was passendes ein, soll das vielleicht IAR > heissen? https://developer.mbed.org/users/okano/notebook/iap-in-application-programming-internal-flash-eras/ http://www.st.com/en/embedded-software/stsw-stm32067.html Johannes S. schrieb: > Der µC muss irgendwie > die Programmierdaten übermittelt bekommen über eine irgendeine > Schnittstelle wie UART, SPI, CAN oder andere. Ja. Aber muss bei mir im Flash zwischengespeichert werden, da die Daten nicht "nativ" sondern in einem Protokoll verpackt kommen. Geht dann IAP nicht mehr!? Grüße Sven
Sven K. schrieb: > Klingt interessant! Auch für einen STM32? Ja. Sven K. schrieb: > Also ist hex zu bevorzugen? Wie schon gesagt wurde: Es gibt keine Standardlösung. Mal kann das besser sein, mal das andere. Ich habs halt bis jetzt immer mit hex gemacht. Sven K. schrieb: > Ja. Aber muss bei mir im Flash zwischengespeichert werden, da die Daten > nicht "nativ" sondern in einem Protokoll verpackt kommen. Das hat nix mit dem Flash zu tun. Den Protokollinhalt (also die binary) extrahierst du beim Empfang. Und zwischenspeichern macht ja wohl auch keinen Sinn. Du kannst ja sofort blockweise in den flash schreiben (dein Bootloader muss/sollte sich dafür vollständig im RAM befinden, ist einfacher). Also warum zwischenspeichern?
Sven K. schrieb: > Ja. Aber muss bei mir im Flash zwischengespeichert werden, da die Daten > nicht "nativ" sondern in einem Protokoll verpackt kommen. Die Daten pufferst du geschickterweise binär, Intel Hex Co. wäre da sehr verschwenderisch und dann müsste ja der µC das Zeug dekodieren. Ablauf wäre also eher: Datei lesen (auf dem Host) - binär extrahieren - in Blöcken an µC übertragen (wie von W.S. beschrieben) - im µC die empfangenen Daten verifizieren und dann ins Flash schreiben (mit den IAP Funktionen).
ui schrieb: > Das hat nix mit dem Flash zu tun. Den Protokollinhalt (also die binary) > extrahierst du beim Empfang. Und zwischenspeichern macht ja wohl auch > keinen Sinn. Du kannst ja sofort blockweise in den flash schreiben (dein > Bootloader muss/sollte sich dafür vollständig im RAM befinden, ist > einfacher). Also warum zwischenspeichern? !?!?!? Wie soll ich denn das ganze Protokollhandling machen, wenn ich die dazugehörigen Sourcecode früher oder Später durch das FW-Update überschreiben würde!? habe gedacht das Image eben in einen anderen Flashbereich zwischenzuspeichern. Und dann dieses Image umkopieren. Die ganzen Sprung- bzw. Funktionsadressen müssen ja auch stimmen...
Hallo Leute, auch ich habe schon mehrere Bootloader geschrieben. Leider bietet das Hex-Format keine Integritätsprüfung für das gesamte Image. Immer nur blockweise. Binär Formate haben weder Information über Startaddresse noch Integrität. Bei meiner Implementierung benutze ich ein Binärformat, wo Startaddress und Image-Checksumme in dem Dateinamen sind. Das war aber alles ganz viel Arbeit. Der STM hat integrierte Bootloader, die per Pin beim Booten aktiviert werden. Es gibt seriell oder/und USB Kommunikation. ST bietet auch die PC Programme an. Falls also deine Schaltung einen Button hat, nur für diesen Zweck - am richtigen Pin, kannst du das STM32 eingebaute IAP Schema benutzen. Adib. --
Sven K. schrieb: > ui schrieb: >> Also warum zwischenspeichern? > > !?!?!? > > Wie soll ich denn das ganze Protokollhandling machen, wenn ich die > dazugehörigen Sourcecode früher oder Später durch das FW-Update > überschreiben würde!? > habe gedacht das Image eben in einen anderen Flashbereich > zwischenzuspeichern. Und dann dieses Image umkopieren. Bonus beim Umkopieren: man hat mehrere Versuche. Die alte Applikation wird nicht zerstört solange es kein gutes neues Image gibt. Selbst wenn beim Umkopieren der Strom ausfällt, ist nichts kaputt. Der Bootloader kann nach jedem Reset prüfen, ob er die Applikation starten kann oder ob er ein gutes neues Image umkopieren kann. Notfalls könnte er noch auf einen neuen Download warten, aber das kann eigentlich nur bei defektem Speicher passieren. Trotzdem kann der Bootloader ziemlich einfach bleiben. Und das Umkopieren geht dann so schnell, wie das Flash schreiben kann. Der Download durch die Applikation darf deshalb auch per Akustik-Koppler passieren ;)
eagle user schrieb: > Der Bootloader kann nach jedem Reset prüfen, ob er die Applikation > starten kann oder ob er ein gutes neues Image umkopieren kann. Notfalls > könnte er noch auf einen neuen Download warten, aber das kann eigentlich > nur bei defektem Speicher passieren. Trotzdem kann der Bootloader > ziemlich einfach bleiben. > > Und das Umkopieren geht dann so schnell, wie das Flash schreiben kann. > Der Download durch die Applikation darf deshalb auch per Akustik-Koppler > passieren ;) Das ist das, was ich benötige! ;-) Gibt es eine Empfehlung, welchen Bootloader ich mir da anschauen kann!?
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.