Grundlegende Fragen zum Bootloader

Ich habe zu genau dem Thema auch ein paar Fragen und ich denke es passt 
hier vielleicht rein.

Also ich habe ein HEX File in dem zB dies hier drinsteht:

:10 0000 00 12C02BC05BC04AC039C027C026C025C0 63
:10 0010 00 24C023C022C022C020C01FC01EC01DC0 DB
:10 0020 00 1CC01BC01AC011241FBECFE5D4E0DEBF 28
:10 0030 00 CDBF10E0A0E6B0E0E6E1F0E102C00590 3F

:10 0040 00 0D92A036B107D9F710E0A0E6B0E001C0 EC
:10 0050 00 1D92A036B107E1F738C1D2CF1F920F92 9F
:10 0060 00 0FB60F921124CF93DF93CDB7DEB7DF91 98
:10 0070 00 CF910F900FBE0F901F9018951F920F92 67
...

Ich habe die Zeilen etwas auseinandergerückt. Wenn ich die Spezifikation 
von Intel da richtig verstanden habe, dann ist 10 die Länge der Bytes im 
Datenfeld hier also 16 (dez). Danach folgen 2 Byte für die 
Anfangsadresse des Datenblocks. Jetzt der Datentyp also 00 bedeutet hier 
Daten. Nun 16Byte Daten und am Ende ein Byte Checksumme. Ist das soweit 
richtig?

Wenn ich nun einen Bootloader bauen möchte, dann würde ich gerne diese 
boot_program_page (uint32_t page) Beispielfunktion verwenden.

Ich dachte mir das in etwa so: Ich lege einen Buffer an der 64 Byte groß 
ist. Lese sozusagen 4 Zeilen aus dem Hexfile in den Buffer und rufe dann 
diese boot_programm_page Funktion auf.

Meine Frage ist nun aber, was muss ich als page übergeben? Ist das immer 
der Offset aus dem Hexfile für die nächsten 65 Byte? Also bei den ersten 
64 Byte 0x0000 beim zweiten schreiben dann 0x0040 usw?

Vielen Dank schonmal
Gruß Philipp

Ja aber man muss ja immer 64Byte (eine Page) auf einmal schreiben, so 
wie ich das verstanden habe, deshalb braucht man auch den Buffer usw. 
Wenn dann müsste man bei einem Sprung (wo kann sowas passieren?) den 
Rest irgendwie auffüllen.

Oder hab ich da was falsch verstanden?

@Herbert worauf bezieht sich das nun?

Das mit dem 2er Komplement werd ich auch gleich mal nachrechnen, ein 
sehr guter Link :)

Was mir noch nicht ganz klar ist: Kann ich an die boot_programm_page() 
Funktion die Startadresse der Daten übergeben, oder werden die Pages 
einzeln durchnummeriert? Also Page 1, 2 , 3 zB mit je 64 Byte oder 
übergebe ich als Page Adresse dann zB 0x0040 für die 2. Page weil es ja 
die nächsten 64 Byte (oben hatte ich irgendwo 65 stehen, sollte 
natürlich 64 sein) sind?

Und auch nochmal zu dem angesprochenem Sprung:
Sollte es nun wirklich in dem Hex File mal so einen Sprung geben, füllt 
man dann Raum zwischen den Adressen mit 0xFF? (Man muss ja die Page 
irgendwie beschreiben)

@Martin, ich hoffe es stört dich nicht, das ich in deinem Thread einfach 
so mit rumfrage, aber ich denke wir stehen vor den gleichen Problemen :)

Vielen Dank schonmal
Gruß Philipp

> Also die CRC ist die Summer der Reste jedn Bytes bei einer Division
> durch 256. Sprich Summer von Moduko 256 bei jedem Byte. Stimmt das so??

Das klingt reichlich kompliziert.

Du zählst einfach alle Bytes zusammen, wobei du eventuelle
Überläufe der Summe von einem Byte ins nächste ignorierst.
Du rechnest einfach alles mit 8 Bit (In Assembler: in
einem Register die Summe bilden und ein eventuelles Carry
bleibt aussen vor. In C: die Summe ist ein uint8_t bzw.
unsigned char)

1. Zeile
10 + 00 + 50 + 00 + 69 + 73 + 20 + 70 + 72 + 6F +
67 + 72 + 61 + 6D + 20 + 63 + 61 + 6E + 6E + 6F

= 683

Da wir aber nur mit Bytes rechnen: 83

Die Prüfsumme ist daher das 2er Komplement davon: FF - 83 + 1 = 7D

Der Sinn der Berechnung des 2er Komplements besteht darin,
dass, wenn ich die Prüfsumme in der Addition auch noch mit
dazu nehme, immer 0 rauskommt.  83 + 7d = 100. Wir rechnen
aber im 8 Bit Raum und ignorieren alle Überträge: Also 00


2. Zeile

10 + 11 + 20 + ein ganzen Haufen 0  = 41

Die Prüsumme ist das 2 er Komplement: FF - 41 + 1 = BF

Beim Testen:
10 + 11 + 20 + ein ganzer Haufen 0 + BF = 100, also 00 -> passt

In Assembler rechnest du das 2 er Komplement natürlich nicht
wie oben aus. Viele Prozessoren haben einen Befehl dafür.
Wenn nicht, dann haben sie einen Befehl für das 1er Komplement
(alle Bits umdrehen) gefolgt von einem inc auf das Register.
Gibt es auch kein 1er Komplement, dann macht man einen
XOR mit FF, gefolgt vom inc

In C würde man wohl auch schreiben:
   Pruef = ~Summe + 1;
oder ganz einfach:
   Pruef = -Summe;

Besonders in der letzten Formulierung ( Pruef = -Summe )
sieht man sehr schön, warum da am Ende 0 rauskommen muss.
Die Prüfsumme wird geerade so konstruiert, dass sie die
Differenz zu 0 ist.

hallo,

>Was mir noch nicht ganz klar ist: Kann ich an die boot_programm_page()
>Funktion die Startadresse der Daten übergeben, oder werden die Pages
>einzeln durchnummeriert? Also Page 1, 2 , 3 zB mit je 64 Byte oder
>übergebe ich als Page Adresse dann zB 0x0040 für die 2. Page weil es ja
>die nächsten 64 Byte (oben hatte ich irgendwo 65 stehen, sollte
>natürlich 64 sein) sind?

woher hast du die routine boot_programm_page()? da sollte zu erfahren 
sein, wie das zu machen ist.

Ich habe diese Funktion identisch in einigen Bootloader gesehen und als 
ich danach gegoogelt habe, habe ich dies hier gefunden:

http://www.nongnu.org/avr-libc/user-manual/group__avr__boot.html

Leider kam dieser Übergabewert immer von der Gegenseite des Bootloaders 
in den Beispielen, die ich gesehen habe, deshalb weiß ich nicht was dort 
eingestzt wurde. Und auch in der Beschreibung aus dem Link hier werde 
ich nicht schlau.

Hat jmd einen Hinweis für mich? Diese Funktion würde ich auch gerne 
benutzen.

Vielen Dank
Gruß Philipp

EDIT: Hmm, wo ich mir die Funktion nochmal so ansehe, da wird die 
Adresse ja bei jedem Byte inkrementiert. Dann erscheint es vielleicht 
doch logisch die Adresse des 1. Bytes der Page zu übergeben. Also um bei 
meinem Beispiel von oben zu bleiben. Bei der 2. Page übergebe ich dann 
0x0040 für die 64Byte in meinem Buffer.
Sehe ich das richtig?

ah ja, sorry, habe ich überlesen (gedanklich zu weit oben).

du nimmst irgend eine adresse aus der page, die du schreiben willst. 
also meinethalben 0x40.
vorher sollte man sich aber einmal schlau machen, wie groß die page auf 
der mcu eigentlich ist. ich bezweifle einfach mal die 64 byte, aber mag 
ja sein. hängt vom controller ab. ist dein puffer kleiner als die page, 
hast du ein problem, da die routine die page vorher platt macht. das 
kann man sicher ändern :) oder aber den puffer so anpassen, das die page 
beim flashen nie wieder angefasst wird. letzteres ist meiner meinung 
nach ein wenig unflexibel, aber soll jeder halten wie er mag.

wo wird denn die adresse inkrementiert?

Die Adresse wird bei jedem Aufruf von boot_page_fill inkrementiert, also 
für das Byte (page + i).

Zu der Page Grösse befrag ich nochmal das Datenblatt, weiß gar nicht 
mehr wo ich die 64Byte her hatte. (Ging um den Mega 8)

Vielen Dank
Gruß Philipp

EDIT: Laut S.225 32 Words -> 64Bytes

ok, wir reden von zwei verschiedenen dingen.

voraussetzungen:
1. der avr besitzt einen sog. temporary buffer. der ist so groß wie eine 
page. der inhalt dieses und NUR dieses puiffers wird in eine page 
geschrieben.

das flash-prozedere lautet daher:
1. der temporary buffer muss gefüllt werden. das nennt sich bei atmel 
"page loading". in der avr-libc nennt sich das boot_page_fill (ist nur 
ein macro). das füllen geschieht word- weise, deswegen der uint16_t im 
beispiel der avr-libc.

2. der inhalt des temporary buffers wird in eine page geschrieben. 
welche page, das hängt vom inhalt des z-pointers ab. die avr-libc fasst 
die schritte dazu mit dem boot_page_write- macro zusammen.

in der doku steht das sehr ausführlich drin, afaik sogar mit einem 
beispiel, wenn auch in asm.

Achso, die Bootloader die ich bisher gesehen habe, die hatten ein 64 
Byte großes Array (dann wohl im RAM), darin wurden die Daten erstmal 
geschrieben, zB vom I2C kommend. Wenn 64 Byte voll waren, dann wurde 
diese boot_program_page() aufgerufen. Aber, wenn es so ist wie du sagst, 
dann kann ich mir doch eigentlich das 64 Byte Array sparen und mit 
boot_page_fill() direkt die Bytes in diesen Puffer schreiben und nach 64 
Bytes einmal boot_page_write() aufrufen. Die page Variable um 64 erhöhen 
und bei boot_page_fill wieder von vorne anfangen.

Oder hab ich das jetzt falsch verstanden?

Gruß Philipp

hm, könnte man - meiner meinung nach - auf den ersten blick so bringen.
vorsicht ist auf jeden fall geboten, da du den temp buffer nur einmal 
pro word schreiben kannst. willst du nochmal auf dieses word schreiben, 
musst du den ganzen puffer kicken (per page write oder rwwscre) und von 
vorne anfangen (seite 216 doku)

die doku vom atmega8 sagt auch, das beim page_write die letzten 6 bit 
der adresse (also im beispiel von "page") auf 0 sein müssen. d.h. 
page-aligned vorgehen, 0x00, 0x40, 0x80, 0xC0, 0x100 usw. sorry, da gabs 
wohl ne änderung zwischendurch.

Das im Ram zwischenzubuffern, hat auch andere Vorteile.
Z.b. kann man mit einem Bottloader, der die Dateien entschlüsselt,
es gibt so auch recht kleine Verschlüsselungsalgorithmen, getrost ein
verschlüsseltes Firmwareupdate rausgeben, ohne daß man das Produkt 
nachbauen
kann und einfach das downloadbare update raufschmeissen kann.
Die Erweiterung zu den bestehenden bootloader gibt es, werden nur nicht
im Internet zum Download bekanntgegeben.

Ja war auch nur eine Frage zum Verständnis. Ich werde am Donnerstag 
(leider kann ich nicht früher, obwohl es langsam in den Fingern juckt :) 
) mal anfangen zu testen.

Das ganze möchte ich für mein Auto haben, um die schlecht zugänglichen 
Module per CAN zu programmieren (keine Angst ist ein eigener CAN Bus, 
einen CAN hatte mein altes Auto vorher gar nicht)

Wenn ich den Bootloader geschrieben habe, wie sag ich dem gcc 
eigentlich, dass es ein Bootloader ist und er das Hex File so anlegt, 
dass zB avr-dude den ganzen Kram in der Bootloader Section ablegt und 
nicht am Anfang des Flash?

Und der Bootloader hat ja eine main() und diesen jump_to_app Kram (der 
einfach auf Adresse 0x0000 springt) Muss ich vorher noch etwas beachten 
oder kann ich (wenn ich die IRQs nicht umgebogen habe) einfach jederzeit 
aus meinem Bootloader in die normale App springen? Dann könnte ich mir 
das doppelte initialisieren des MCP2515 sparen, weil das ja schon der 
Bootloader erledigt hat. Und muss in der App danach noch etwas beachtet 
werden oder kann ich die so programmieren wie früher auch mit einer 
main() usw? (zweimal main() sollte ja egal sein, weil es ja woanders 
liegt)

Vielen Dank schonmal
Sorry das es so blöde Fragen sind, aber ich habe bisher keine Antworten 
dazu gefunden.

Gruß Philipp

Also, bei den bootloadern über i2c, can usw. ist es üblich, daß
die Applikation zum Bootloader springt, nicht umgekehrt.
Dies ist darin begründet, daß das modul nur über ein Netzwerk erreichbar
ist, eben nicht direkt. Üblicherweise haben die eine fixe serielle 
number,
die Eindeutig ist, z.B jahr,monat,tag,id als 32bit nummer sowie eine 
kleinere
16bit Random sowie eine 8bit priorität und eine 8bit produktnummer, mit 
der
gewisse Verhalten gesteuert werden, die dann nötig sind, um so ein 
Netzwerk
von unprogrammierten Modulen gleichzeitig in kurzer zeit über das 
Netzwerk
zu lokalisieren, steuern und uploaden. Es kann noch einen hw-jumper 
geben,
wobei dann der bootloader einspringt, aber die ist eigentlich nur für 
den
absoluten Fehlerfall.

Naja die CAN Funktionen brauche ich ja eh in der Anwendung und in dem 
Bootloader. Ich dachte mir aus Sicherheitsgründen startet es ganz normal 
wie die seriellen Bootloader mit dem Bootloader, so ist sichergestellt, 
dass ich das Modul immer flashen kann notfalls indem ich kurz den Strom 
unterbreche (Jumper ist schlecht, weil zB je ein Modul in der Tür ist da 
müsste ich zum Jumpern die Türverkleidung entfernen).

Den Bootloader wollte ich vom Programm anspringen, indem ich über eine 
CAN Nachricht das Modul in eine Endlosschleife springen lasse und so der 
Watchdog das Modul neustartet.

Oder gibt es weitere Gründe den Bootloader aus der Applikation 
anzuspringen und diesen nicht beim start anzuspringen?

Gruß Philipp

EDIT: Der Bootloader muss dafür natürlich direkt pro Modul ansprechbar 
sein.

Und was ist, wenn das Modul aufgrund eines Fehlers/EMF/... per Watchdog
rebootet, kann dann das Modul und der Flash korrumpiert werden ?
Weiters, wenn du mehrere module hast, und du den Strohm wegnimmst,
dann kannst du nicht alle gleichzeitig Flashen. OK, die haben eine 
eindeutige
CAN-Addresse, aber was, wenn das neue Firmware nicht funkt und den WDT
aktualisiert. Dann musst du einen cold-reset machen, und alle module
wollen neu geflasht werden.

Bootloader für mega8 und mega32 über CAN gibt es bei dem HCAN projekt.
Solltest dir mal ansehen.

Warum sollte ich nicht alle gleichzeitig Flashen können? Außerdem ist 
das doch auch nicht notwendig. Ich habe mir vorgestellt, das sie beim 
starten eine Meldung senden welche Firmware Version sie zur Zeit haben 
und warum sie resetet haben (das mache ich auch jetzt schon). Darauf 
bekommen sie vom PC dann entweder den Befehl eine neue Firmware zu 
empfangen oder ganz normal die Firmware zu starten. Kommt diese Meldung 
meinetwegen nicht innerhalb von 500ms so starten sie ganz normal die 
Firmware.

Also ein Watchdog reset würde das Modul dann maximal 500ms ausser 
Gefecht setzen, aber wenn der auftritt läuft eh irgendwas nicht richtig.

Wenn das Modul wirklich aufgrund falscher Firmware zwar den Watchdog 
resetet, aber trotzdem nicht auf CAN Nachrichten hört, dann kann ich 
immernoch einfach die Sicherung rausziehen und wieder reinstecken. Ich 
kann doch trotzdem per CAN gezielt einem Modul sagen, dass es nun eine 
neue Firmware bekommt. Die anderen starten eh nach 500ms neu (falls sie 
mit an der Sicherung hingen) oder sie bekommen sofort die Nachricht, 
dass sie normal starten sollen.

Habe ich dabei etwas übersehen? Wie gesagt bisher sind das nur meine 
Gedanken noch läuft es nicht so.

Gruß Philipp

Edit: Gerade das Szenario mit dem falschen Firmware die den Watchdog 
trotzdem zurücksetzt spricht IMHO für die Version mit dem starten des 
Bootloaders beim Reset, denn sonst kann man das Modul ja gar nicht mehr 
flashen ohne diesen oben erwähnten Jumper. (Denn die falsche Firmware ja 
auch ignorieren könnte)

Hi!

Ich hoffe ich darf mich hier auch einklinken, denn ich habe sehr 
ähnliche Probleme.

Basis bei mir ist ein ATmega32, auch er hat Pages a 64 Bytes. Das mit 
den Pages ist vollkommen OK und meine Software braucht auch nur in Pages 
aktualisiert zu werden.
Ein Problem habe ich schon gelöst, da man im GCC eigene Segmente 
definieren kann und daher kann ich Versionsnummern und andere Infos in 
der letzten Page unter dem Bootloader unterbringen.

Ein großes Problem habe ich aber mit dem Bootloader:
Entweder muss ich ihn in das Projekt selbst einbinden. Das würde mir 
helfen, da ich komplexe Serielle Treiber für ein unidirektionales sehr 
schnelles RS485 Netz nur einmal schreiben brauche und diese auch aus der 
Cleint-Software nutzen kann. Das würde es aber notwendig machen, ggf. 
auch den Bootloader selbst austauschbar zu machen. Aus 
Sicherheitsgründen muss also ein Bootloader-Bootloader ins System. Oder 
ISP ist angesagt. Macht Spaß bei 100 Modulen pro Schrank und mind. drei 
Schränken. Ist etwa so nervig, wie das zerlegen und zusammenbauen von 
Autotüren mit Folienversiegelung.

Also die andere Version:
Der Bootloader enthält eine abgespeckte Version der RS485 Treiber und 
ist autark. Also müssen keine Querverweise in der Software auf ihn 
existieren und nur eine virtuelle Funktion für seinen Ansprung ist 
nötig.
Aber nun kann AVR Studio mit AvrGCC nicht mehr mithalten. Die Summe 
aller Segmente ist immer der komplette Flash des mega32. Ich finde keine 
Option dem LD beizubringen, dass mein mega32 nur ein Flash von 0x3800 
hat.

Wie kann ich das dem Linker beibringen? Ich hab schon gesucht, aber ich 
sehe es nicht. Die beschriebene Lösung würde auch Philipp helfen, denke 
ich.

Danke im Voraus
Ulrich

Alle Megas >=8kB

außer Mega103

Peter

hi

die funktion könnte ganz nützlich sein für dich.

Beitrag "Hexastring konvertieren"