Hallo Zusammen, Eine Frage ist hier jemand der vielleicht auch einen Bootloader verwendet auf einem XMC4500 oder STM32 der auch CRC geschützt die Applikation anspringt. Also ich rede nur von einem Bootloader und von einer Applikation. Es gibt ja auch andere varianten. Ich mach das eigentlich schon lange - komme aus der XC167 und XE167 Welt. Bei den Controllern habe ich das immer so gemacht das ich mit SRecord an einen bestimmten bereich im Flash die CRC geschrieben habe. Beim Booten habe ich dann die CRC überprüft und falls diese gleich war wie die abgelegte habe ich noch einen Zeitstempel zusätzlich abgelegt.... Funktionierte über die Jahre perfekt. Mein Problem nun ist bei den neuen Controllern gibt es im Flash keine kleinen Bereiche mehr man kann nur noch Sektoren löschen und wiederbeschreiben. Beim XMC4500 hieße das sogar 16KB für 2 uint16_t zu opfern. Damals gab es ja noch einen Page Erase und Page Write. Und da das ja im Lebenszyklus nicht so oft vorkommt war das für das Flash auch kein Problem. Jetzt dachte ich mir in nehme eine EEPROM Flash Emulation als speicher. Das Problem ist dann kann ich nicht mit SRECORD die crc berechnen und im Build ablegen. Aber ich könnte die CRC beim Builden wieder mit SRECORD berechnen und ablegen und beim Booten vergleichen ob diese im EEPROM steht wenn nicht mache ich ein Update dieser CRC und der Vergleich nimmt dann diese im EEPROM. Das Datum kann ich dann einfach nur fix an die EEPROM Address legen. Hätte jemand ne bessere Idee? Echt Schade, dass die solche Controller nicht auch mal mit ei paar Byte EEPROM ausstatten. :-( Wie macht ihr das so? Danke sg
Eigentlich benoetigt man ja nur den CRC beim Uebertragen der Firmware durch den Bootloader, um auf Korrektheit und vollstaendigkeitzu pruefen. Am Ende der Programmierung genuegt ja ein einzelnes bit, das man noch schreibt - alles io, oder eben nicht. Egal, man kann auch einen CRC beim Schreiben des Flash anhaengen. Ein Datum, kann man ja auch gleich beim Schreiben einfuegen. Und ja, meine Controller haben ein internes EEPROM fuer Parametrierdaten und solche Information.
Ich mache das immer so bei meinen STM32. Die Controller haben immer unterschiedliche Größen der Pagen. So kommt am Anfang der Bootloader, in den Pagen danach die CRC oder EEprom Emulation. Und danach die Firmware. Z.B.: Page 1: Bootloader Page 2: Eepromemulation Page 3: Eepromemulation Page 4 ....: Firmware Das funktioniert ganz gut und das kannst du über das Linkerscript machen.
clonephone82 schrieb: > Bei den > Controllern habe ich das immer so gemacht das ich mit SRecord an einen > bestimmten bereich im Flash die CRC geschrieben habe. Beim Booten habe > ich dann die CRC überprüft und falls diese gleich war wie die abgelegte > habe ich noch einen Zeitstempel zusätzlich abgelegt Was ist der tiefere Sinn hinter dem Zeitstempel? Ich habe eine Applikation, bei der das Firmware-Update mit dem Bootloader aus der normalen Applikation heraus mit einem Befehl gestartet wird. Wenn jetzt natürlich die normale Applikation kaputt ist geht das nicht. Daher vergleicht der Bootloader immer die CRC des tatsächlichen Inhalts mit der Soll-CRC der Applikation. Diese steht in den letzten 4 Bytes des Flashs. Wenn die CRC nicht stimmt, springt er immer in den Bootloader-Modus und erwartet ein Firmware-Update. Ansonsten startet er die normale Applikation. Dafür brauche ich aber keinen Zeitstempel.
Ich arbeite für solche Zwecke mit kleinen DOS Applikationen, die ich zu Batchfiles zusammenschnüre. Die erste utility (objcopy) macht aus was immer der linker generiert ein binäres 1:1 Image, die zweite berechnet darüber die CRC, hängt sie hinten an und legt Alles in ein neues file ab, und die Dritte (vielfalls wieder objcopy oder ein S-Record Generator) macht daraus wieder das Format, das ich zum Flashen brauche. In der Praxis ist aber für einen Remote Download ein aufgeblasenes Format wie S-records eher ungebräuchlich, ausser vielleicht für den Bootloader selber (also bei der Erstinbetriebnahme, je nachdem welche Programmierutility eingesetzt wird). Ich mache es meistens so, dass einmalig ein Bootloader eingebrannt wird und ein Hostinterfacesimulator das Applikationsimage so hereinspielt, als würde es im Laufenden Betrieb einen Update geben. Im Feld werden bei den Systemen, an denen ich arbeite, die Images sowieso nur "roh" (also binär) von A nach B geschoben, dann passt es. Für den Bootloader selber ist eine CRC allerdings nur dann nötig, wenn der Bootloader selber upgradbar ist.
Ich verstehe nicht, warum die CRC an einer separaten Stelle gespeichert werden soll. Ich integriere beim Build-Prozess die CRC in das Firmware-Binary. Dieses wird vom Bootloader als Ganzes ins Flash geschrieben, ohne Firmware und CRC in irgendeiner Weise getrennt zu behandeln. Übrigens steht bei mir die CRC nicht am Ende des Binary, sondern zusammen mit einer Längenangabe am Anfang. Da bei uns bei vielen Anwendungen das Flash oft nur zur Hälfte gefüllt ist, verkürzt sich dadurch die Update-Zeit dramatisch. Viele Grüße, Stefan
Hallo, @alle danke. Ich mache es jetzt mit einer EEPROM emulation. Das mit dem Datum dient dazu zu entscheiden ob nachgeladen werden soll oder nicht. Das hat aber mit dem Systemaufbau von uns zu tun also nicht weiter wichtig. @stefan .. Ja das mache ich ja auch so bezüglich Build Process, das mit der Länge nicht. Wäre aber eine gute Optimierung - Danke. sg mathias
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.