STM32 + IAP + Dateiformat?

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!?

Wie? Hat keiner eine Empfehlung?