Nakkaloader: Unterschied zwischen den Versionen

Version vom 25. Februar 2009, 00:38 Uhr

Der Nakkaloader ist ein Bootloader für Atmel AVR Microcontroller, der es erlaubt diese Geräte via Funk zu flashen.

Das Projekt besteht aus zwei Softwarekomponenten: Auf der Hostseite sendet das Flasher-Tool die Firmware an den eigentlichen Bootloader, der sich auf dem Microcontroller befindet.

Zur Datenübertragung benutzen wir die RFM12 Funkmodule von Hoperf. Zur Ansteuerung haben wir eine eigene Library entwickelt.

Damit man mit handelsüblichen PCs auch arbeiten kann, haben wir uns zunächst ein kleines Debugtool gebaut: Ein Funk zu USB Adapter (rfm12usb). Den Quellcode für dessen Firmware gibt es ebenfalls im svn.

Installation

Zur Installation auf dem Microcontroller sind im Grunde nur folgende Schritte notwendig:

SVN auschecken (siehe link unten)
in's Verzeichnis nakkaloader/firmware wechseln
die rfm12_config.h anpassen (insbesondere Chipselect-Pin ggf. ändern)
make ausführen
Gerät flashen
fuses ggf. neu setzen. (BOOTSZn bits auf entsprechende Größe (2KB), sowie BOOTRST bit setzen)

Fuses

Damit der Bootloader auch angesprungen wird, müssen die Fuses entspechend gesetzt werden. Hier sind ein paar häufig verwendete Konfigurationen:

MCU	Fusebit	Bits	Bitwert
Atmega8	High Byte	letzten 3	0x0

Protokoll

Nakkaloader Protokoll 1.0

Das Protokoll des Nakkaloaders ist relativ simpel: Der Microcontroller (client) sendet solange seine Konfiguration, bis entweder ein Timeout eintritt oder der Master (Flasher) antwortet. Wenn niemand antwortet wird die Applikation ganz normal gestartet. Wenn eine Antwort kommt, wartet der loader auf Daten und Instruktionen vom Master.

Diese Instruktionen können wie folgt sein:

Pagebuffer füllen (PAGE_FILL)

Der loader lädt die empfangenen Daten in einen Buffer, bildet eine crc16 checksumme darüber und schickt dem Master die Checksumme zurück.

Page schreiben (PAGE_COMMIT)

Der Pagebuffer wird an in die vorgegebene Page geschrieben.

Applikation booten (BOOT)

Die Interrupts werden abgeschaltet und dann die Applikation gestartet.

Fehlerbehandlung

Der Microcontroller selbst bildet lediglich eine CRC16 Checksumme der Daten, jedoch nicht, ob der Host (Master) ihm alle Daten schon geschickt hat oder etwa ob die angekommenen Daten korrekt sind.

Diese Aufgabe wird aus Platzgründen (das Ding muss schliesslich unter 2KB bleiben) auf den Host verlegt. Wenn der Host einen CRC16 Fehler entdeckt, schickt er die Daten einfach nochmal.

Natürlich wäre es auch möglich, auf dem Microcontroller auch die Fehlerbehandlung zu erledigen, allerdings würde dies das Protokoll unnötig verkomplizieren und höchstwahrscheinlich die 2KB-Grenze sprengen.

Sicherheit

Der Nakkaloader sichert lediglich die Integrität der Daten so gut es eben mit CRC16 möglich ist. Schutzziele wie Vertraulichkeit oder Authentifikation erfüllt er nicht, weil schlicht der Speicherplatz nicht ausreicht. Ein Grund für den Speicherplatzverbrauch ist, das die RFM12 Library an sich schon ein Kilobyte einnimmt. Sollte jemand eine RFM12 library unter GPL Lizens in assembler parat haben, die deutlich kleiner ist, wäre es z.B. möglich die Blockchiffre Noekeon aus der AVR-Crypto-Lib zu nehmen.

Quellcode im SVN: microcontroller/src-atmel/rfm12/nakkaloader/

@@ Zeile 56: / Zeile 56: @@
 == Sicherheit ==
 Der Nakkaloader sichert lediglich die Integrität der Daten so gut es eben mit CRC16 möglich ist. Schutzziele wie '''Vertraulichkeit''' oder '''Authentifikation''' erfüllt er nicht, weil schlicht der Speicherplatz nicht ausreicht. Ein Grund für den Speicherplatzverbrauch ist, das die RFM12 Library an sich schon ein Kilobyte einnimmt.
-Sollte jemand eine RFM12 library unter GPL Lizens in assembler parat haben, die deutlich kleiner ist, wäre es z.B. möglich die Blockchiffre Noekeon aus der [[Crypto-avr-lib]] zu nehmen.
+Sollte jemand eine RFM12 library unter GPL Lizens in assembler parat haben, die deutlich kleiner ist, wäre es z.B. möglich die Blockchiffre Noekeon aus der [[AVR-Crypto-Lib]] zu nehmen.