eigener Bootloader für Arduino Due

[Rahul D. (rahul)]

Moin,
ich würde gerne einem Arduino Due-System die Möglichkeit geben, sich 
selbst eine neue Firmware zu verpassen (neben dem USB-Bootloader im 
ROM).

Dazu habe ich mir die Application Note AT02333 von Atmel 
(http://www.atmel.com/Images/Atmel-42141-SAM-AT02333-Safe-and-Secure-Bootloader-Implementation-for-SAM3-4_Application-Note.pdf) 
durchgelesen.

Mir würde die Variante mit dem dual Bank System sehr gut gefallen, und 
ich vermute, dass ich das sogar im Arduino Dialekt hinbekäme (die 
Firmware ist in Arduino geschrieben).
Meine Verständnisprobleme:
- Wie teile ich dem Compiler (arm-none-eabi-g++) mit, dass er nur noch 
256K statt des kompletten Speicherraums zur Verfügung hat?
- Bzw. wie bekomme ich den Speicher entsprechnd aufgeteilt? (Das IAR 
Beispiel gucke ich mir auch noch an).

- Muss der Bootloader ein eigenständiges Programm sein, oder kann er 
auch teil meiner Anwendung sein, die beim Booten nach einer 
Firmwarequelle guckt und sonst den bisherigen Programmablauf abarbeitet?
Im Prinzip wäre meine Anwendung dann (gleichzeitig) der Bootloader.

So, wie ich die Application Note verstanden habe, kann man durch Setzen 
der GPNVM-Bits den Bootbereich festlegen. Das könnte ich auch im 
"Hauptprogramm" erledigen.

Vielen Dank im Voraus,

Rahul

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Moin Moin,

Rahul D. schrieb:

> - Wie teile ich dem Compiler (arm-none-eabi-g++) mit, dass er nur noch
> 256K statt des kompletten Speicherraums zur Verfügung hat?

im Linker-Script steht, wie lang bestimmte Speicherbereiche sind.

> - Bzw. wie bekomme ich den Speicher entsprechnd aufgeteilt? (Das IAR
> Beispiel gucke ich mir auch noch an).

Zwei Linker-Scripte mit entsprechenden Einstellungen für Start-Adresse 
und Länge. Zusätzlich musst Du Dir dann noch Gedanken machen, wie die 
Interrupt-Vektoren verbogen werden sollen.

> - Muss der Bootloader ein eigenständiges Programm sein, oder kann er
> auch teil meiner Anwendung sein, die beim Booten nach einer
> Firmwarequelle guckt und sonst den bisherigen Programmablauf abarbeitet?

Das Problem ist, dass der Bootloader beim Firmware-Update natürlich 
komplett laufen muss. Wenn jede Firmware Version einen bootloader 
enthält, brauchst Du Platz im Speicher für zwei komplette Firmware inkl. 
zwei Bootloader. Bei der Trennung von Firmware und Bootloader brauchst 
Du nur Speicherplatz für einen Bootloader und eine Firmware (exkl. 
Bootloader).

mfg Torsten

[Rahul D. (rahul)]

Torsten R. schrieb:
> Moin Moin,
>
> Rahul D. schrieb:
>
>> - Wie teile ich dem Compiler (arm-none-eabi-g++) mit, dass er nur noch
>> 256K statt des kompletten Speicherraums zur Verfügung hat?
>
> im Linker-Script steht, wie lang bestimmte Speicherbereiche sind.
>
>> - Bzw. wie bekomme ich den Speicher entsprechnd aufgeteilt? (Das IAR
>> Beispiel gucke ich mir auch noch an).
>
> Zwei Linker-Scripte mit entsprechenden Einstellungen für Start-Adresse
> und Länge. Zusätzlich musst Du Dir dann noch Gedanken machen, wie die
> Interrupt-Vektoren verbogen werden sollen.
>
>> - Muss der Bootloader ein eigenständiges Programm sein, oder kann er
>> auch teil meiner Anwendung sein, die beim Booten nach einer
>> Firmwarequelle guckt und sonst den bisherigen Programmablauf abarbeitet?
>
> Das Problem ist, dass der Bootloader beim Firmware-Update natürlich
> komplett laufen muss. Wenn jede Firmware Version einen bootloader
> enthält, brauchst Du Platz im Speicher für zwei komplette Firmware inkl.
> zwei Bootloader. Bei der Trennung von Firmware und Bootloader brauchst
> Du nur Speicherplatz für einen Bootloader und eine Firmware (exkl.
> Bootloader).
>
> mfg Torsten

Danke für die Antwort.
Ich bin inzwischen soweit, dass ich den Bootvektor verbiegen und auch 
die neue von meiner Quelle einlesen und (über die serielle 
Schnittstelle) ausgeben kann.

Was mir jetzt schleierhaft ist:
Wie schreiben ich die Daten ins Flash?
In der Atmel-Doku wird ein Beispiel gezeigt, wie es mit der 
IAR-Workbench läuft. Da endet der Detailierungsgrad aber bei einer 
Funktion namens "FLASHD_Write".
Ich habe ja die einzelnen Adressen der Flash-Bänke, aber mir fehlt die 
Vokabel, mit der ich den Zwischenspeicher beschreibe und dann per EEFC 
die Seite ins Flash schreibe (bis jetzt hatte ich nie was mit ARM zutun, 
sondern nur mit 8bitter).

Es wäre nett, wenn mir jemand auf die Sprünge helfen würde.
Vielen Dank!
Rahul

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Hallo Rahul,

Rahul D. schrieb:

> Was mir jetzt schleierhaft ist:
> Wie schreiben ich die Daten ins Flash?

ich habe mit Atmel Controllern auch noch nix gemacht. Bei vielen 
Controllern findest Du im Reference-Manual ein Peripheral das irgend wie 
Flash Controller oder Memory Controller heißen wird.

> In der Atmel-Doku wird ein Beispiel gezeigt, wie es mit der
> IAR-Workbench läuft. Da endet der Detailierungsgrad aber bei einer
> Funktion namens "FLASHD_Write".

Vielleicht liefert Atmel eine Library, in der diese Funktionen enthalten 
sind? Guck mal in den headern die Du evtl. von Atmel bekommen hast.


mfg Torsten

[beric (Gast)]

Rahul D. schrieb:
> Mir würde die Variante mit dem dual Bank System sehr gut gefallen,

Torsten R. schrieb:
> Bei der Trennung von Firmware und Bootloader brauchst
> Du nur Speicherplatz für einen Bootloader und eine Firmware (exkl.
> Bootloader).

Bootloader 1x, Firmware 2x. Falls ein FW Update in einen Bank mal fehl 
schlägt kann man noch die alte FW im anderen Bank starten...

[Amateur (Gast)]

In der Praxis läuft das Ganze darauf hinaus, dass Du für 3 Programme 
Platz brauchst.
1. Bootloader mit Reserve, wenn der "neue" größer wird.
2. Bootloader mit Reserve, für den der gerade überschrieben wird.
3. Das eigentliche Programm mit Platz für Erweiterungen.
Mehrere Vektortabellen.
1. Für den ersten Bootloader.
2. Für den zweiten Bootloader.
3. Für das Hauptprogramm.

Das kann schnell Zuviel werden.

Ich weiß nicht wie Komfortabel die Selbstprogrammiereigenschaften des 
gewünschten Prozessort sind. Eventuell gäbe es nämlich noch die 
Möglichkeit folgendermaßen zu arbeiten:
- Du implementierst eine vom Bootloader unabhängige Kopierroutine.
- Du lädst den neuen Bootloader in den Bereich, indem sich das
  eigentliche Programm befindet.
- Du startest die Kopierroutine, die bei deaktivierten Vektoren, den
  neuen Bootloader über den alten schreibt.
- Du aktivierst die Vektoren wieder.
- Du lädst das Programm (eventuell gleich ein Neues) erneut.

Hauptnachteil ist der, dass Du immer das Hauptprogramm erneut laden 
musst.