4.5
Rollenverteilung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5.1
Funktion des Bootloaders . . . . . . . . . . . . . . . . . . . . . . . 31
4.5.2
Aufgaben der Anwendung . . . . . . . . . . . . . . . . . . . . . . . 32
4.5.3
Rolle des Host-PC . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.6
Sicherungsmechanismen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.6.1
Spannungsversorgung des MSP430 . . . . . . . . . . . . . . . . . . 33
4.6.2
Resets des MSP430 . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.6.3
¨
Uberschreiben des Bootloaders . . . . . . . . . . . . . . . . . . . . 34
4.6.4
Defekte Daten
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.7
Interrupt Weiterleitung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.7.1
Feste Interrupt Vektor Tabelle im Flash-Speicher . . . . . . . . . . 35
4.7.2
Dynamische Interrupt Vektor Tabelle im RAM . . . . . . . . . . . 37
4.8
Platzierung des Bootloaders im Speicher . . . . . . . . . . . . . . . . . . . 38
4.8.1
Bootloader am Anfang ohne Interrupt Routing . . . . . . . . . . . 38
4.8.2
Bootloader am Anfang mit Interrupt Routing . . . . . . . . . . . . 39
4.8.3
Bootloader am Ende mit Interrupt Routing . . . . . . . . . . . . . 40
4.8.4
Bootloader am Ende ohne Interrupt Routing . . . . . . . . . . . . 41
4.8.5
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.9
EEPROM Speicheraufteilung . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.9.1
Firmware-Image Verwaltung . . . . . . . . . . . . . . . . . . . . . . 43
5
Implementierung
47
5.1
Treiber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1.1
USART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1.2
SPI
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1.3
EEPROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.1.4
Flash
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.2
Bootloader
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2.1
Interrupt Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2.2
Bootloader API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.3
Tool-Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6
Test
64
6.1
Probleme beim Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.2
Flash-Speicher ¨
Uberpr¨
ufung . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.3
Test im Sensornetz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.3.1
Testaufbauten
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
ii
6.4
Testergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7
Zusammenfassung
70
iii
Abbildungsverzeichnis
2.1
Sterntopologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2
Baumtopologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3
Vermaschtes Netz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.4
Speicheraufteilung des Atmel AVR . . . . . . . . . . . . . . . . . . . . . .
8
3.1
Sensorknoten S1, Originalmaße: 3,6cm x 8,5cm x 0,5cm
. . . . . . . . . . 16
3.2
Adressraum des MSP430 F1611 . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3
Evaluation-Board f¨
ur Sensorknoten . . . . . . . . . . . . . . . . . . . . . . 18
3.4
Beispiel einer Vernetzung mit Slotted-MAC . . . . . . . . . . . . . . . . . 23
3.5
IAR Workbench
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1
Ablauf eines Firmware Updates . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2
Ablauf der Interrupt Verarbeitung mit fixem Interrupt-Routing . . . . . . 37
4.3
Bootloader am Anfang ohne Interrupt Routing . . . . . . . . . . . . . . . 39
4.4
Bootloader am Anfang mit Interrupt Routing . . . . . . . . . . . . . . . . 40
4.5
Bootloader am Ende mit Interrupt Routing . . . . . . . . . . . . . . . . . 41
4.6
Bootloader am Ende ohne Interrupt Routing
. . . . . . . . . . . . . . . . 42
4.7
Speicheraufteilung des EEPROM . . . . . . . . . . . . . . . . . . . . . . . 43
4.8
Verweis auf ein komplettes Firmware Image . . . . . . . . . . . . . . . . . 45
4.9
Verweis auf Segmente f¨
ur Teilaktualisierung . . . . . . . . . . . . . . . . . 46
5.1
Kontrollfluss in spi write . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2
Kontrollfluss beim Start des Bootloaders . . . . . . . . . . . . . . . . . . . 56
5.3
Implementierte Speicheraufteilung des EEPROM . . . . . . . . . . . . . . 61
5.4
KOMBooterSuite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.1
Debugger mit Flash-Speicher Ansicht . . . . . . . . . . . . . . . . . . . . . 66
6.2
Testaufbauten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
iv
Tabellenverzeichnis
2.1
M¨
ogliche Gr¨
oßen des AVR Bootloaders . . . . . . . . . . . . . . . . . . . .
9
2.2
M¨
ogliche Platzierungen der Interrupts beim AVR . . . . . . . . . . . . . .
9
2.3
Intel Hex Format Zeilenaufbau . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1
Einfacher Image Entry Aufbau . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2
Erweiterter Image Entry Aufbau . . . . . . . . . . . . . . . . . . . . . . . 44
6.1
Befehle der SMMART-Testanwendung . . . . . . . . . . . . . . . . . . . . 68
v
Listings
2.1
TI TXT Beispieldatei
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2
Intel HEX Beispieldatei . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1
usart init Signatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2
USART Konfigurationsbeispiel . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3
SPI Treiber API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.4
SPI Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.5
EEPROM Treiber API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.6
Funktion eeprom write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.7
EEPROM Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.8
Flash Treiber API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.9
Interrupt Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.10 Konfigurationsdatei f¨
ur den Linker . . . . . . . . . . . . . . . . . . . . . . 58
5.11 Dynamischer Interrupt Handler Beispiel . . . . . . . . . . . . . . . . . . . 58
5.12 Interrupt Verarbeitung im Bootloader . . . . . . . . . . . . . . . . . . . . 59
5.13 Bootloader API in boot.h . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
vi
1 Einleitung
Drahtlose Sensornetze sind ein Einsatzgebiet von Mikrocomputern welches in Zukunft
eine bedeutende Rolle spielen wird und sich schon heute bew¨
ahrt hat. Sie dienen dazu
Daten in Bereichen zu erfassen, die keine feste Installation von Kommunikationswegen
zulassen oder wo die ben¨
otigte Mobilit¨
at eine feste Verkabelung unm¨
oglich macht, wie
zum Beispiel bei der Lokalisierung von Waren in einem Lager. Der heutige Stand der
Technik erlaubt es mit ¨
außerst stromsparenden Mikroprozessoren und effizienten Kom-
munikationsverfahren, dass ein Datenerfassungssystem in einem drahtlosen Sensornetz,
ein so genannter Sensorknoten, ¨
uber Monate oder sogar Jahre hinweg st¨
andig ohne Aus-
tausch der Energieversorgung v¨
ollig autark arbeiten kann.
Solche Systeme werden nat¨
urlich nicht nur als reine Hardware-L¨
osung hergestellt, son-
dern besitzen eine spezielle, f¨
ur einen bestimmten Einsatzzweck entwickelte, Software.
F¨
ur eine Aktualisierung dieser Software ist es zwar m¨
oglich einen Sensorknoten an einen
normalen Arbeits-PC anzuschließen, allerdings st¨
ort dies den laufenden Betrieb des Sen-
sornetzes. Daher ist es sinnvoll eine Aktualisierung der Software f¨
ur solche Sensorkno-
ten ¨
uber die bestehende Kommunikationsinfrastruktur des Sensornetzes anzustreben.
F¨
ur diese Aktualisierungsmethode gibt es schon bestehende L¨
osungen f¨
ur verschiedene
Software- und Hardware-Systeme im Bereich der drahtlosen Sensornetze.
Das Fraunhofer Institut f¨
ur Integrierte Schaltungen arbeitet an einer Implementierung
eines eigenen Hard- und Software-Systems f¨
ur drahtlose Sensornetze. Im Rahmen dieser
Diplomarbeit sollte f¨
ur einen integralen Bestandteil eines m¨
oglichen Aktualisierungme-
chanismus dieser Sensorknotenplattform, n¨
amlich der Bootloader-Teil, zuerst ein Kon-
zept und dann eine darauf aufbauende Implementierung erstellt werden. Dazu wurden
andere Systeme untersucht und darin verwendete Techniken auf Einsatzm¨
oglichkeit im
Kontext des Fraunhofer Systems ¨
uberpr¨
uft. Bei der Erstellung des Konzepts wurde be-
sonders darauf geachtet, dass die Implementierung eines Bootloaders im Rahmen der
M¨
oglichkeiten eine m¨
oglichst hohe Ausfallsicherheit bietet um so die Anforderung des
1
autarken Betrieb des Sensornetzes zu unterst¨
utzen. Hierzu wurden veschiedene Mecha-
nismen zur Sicherung der Betriebsf¨
ahigkeit des Sensorknoten entwickelt.
Die Implementierung selbst besteht zum großen Teil aus Treibern f¨
ur die spezielle ver-
wendete Hardware, einer Logik, welche die Verwaltung von Firmware-Images
1
¨
uber-
nimmt, sowie der Weiterleitung der Hardware-Interrupts vom Bootloader zur laufen-
den Anwendung. Zu den vom Umfang her kleineren, aber nicht weniger wichtigen Tei-
len geh¨
ort die ¨
Uberpr¨
ufung der Spannung und die Aktualisierungsroutine, welche die
tats¨
achliche Aktualisierung der Sensorknoten-Software ¨
ubernimmt. Um auch von einem
Arbeits-PC aus die Aktualisierung ¨
uber das Sensornetz vornehmen zu k¨
onnen, wurde ei-
ne spezielle Software auf Basis der Eclipse Rich-Client-Plattform entwickelt. Die Eclipse
RCP erm¨
oglicht es, durch eine Plug-In Infrastruktur verschiedene Aktualisierungsme-
thoden in diese Anwendungssoftware zu integrieren.
Da der Bootloader nur einer von mehreren Teilen ist, die an einem Aktualisierungsprozess
Teilnehmen, kann die erfolgte Implementierung nur als Protoyp betrachtet werden, wel-
cher in ein Gesamtsystem integriert werden muss. Deshalb musste zus¨
atzlich f¨
ur den Test
des Bootloaders auf korrekte Funktion eine ¨
Ubertragungsm¨
oglichkeit f¨
ur eine Software-
Aktualisierung, basierend auf einer bestehenden ¨
Ubertragungssoftware vom Fraunhofer
Institut, implementiert werden. Diese prototypische Implementierung eines Bootloaders
bildet am Ende die Basis f¨
ur ein gesamtheitliches Aktualisierungsverfahren, welches um
die fehlenden Teile, wie ein effizientes ¨
Ubertragungsverfahren f¨
ur Firmware-Images, er-
weitert werden muss.
In den nachfolgenden Kapiteln 2 und 3 wird auf die allgemeinen und die f¨
ur das Fraun-
hofer Institut spezifischen Grundlagen eingangen, um den Kontext n¨
aher zu erl¨
autern.
Das Kapitel 4 beschreibt die Konzeption der Aktualisierung aus Sicht des Bootloaders
und dessen Funktionalit¨
at und Funktionsweise. Die tats¨
achliche Implementierung wird
in Kapitel 5 vorgestellt und zeigt die erw¨
ahnte prototypische Umsetzung des Konzepts.
Anschließend wird im 6. Kapitel auf die Probleme und Eigenheiten beim Test des Boot-
loaders eingegangen, bevor im 7. und letzten Kapitel eine Zusammenfassung einen Aus-
blick f¨
ur die Zukunft des Bootloaders gibt.
1
Programm-Code, welcher auf einem bestimmten Ger¨
at ausgef¨
uhrt werden kann
2
2 Allgemeine Grundlagen
In diesem Kapitel wird auf die allgemeinen Grundlagen eingegangen und Begriffe ein-
gef¨
uhrt, die f¨
ur das Verst¨
andnis der restlichen Kapitel notwendig sind. Zuerst werden
drahtlose Sensornetze und deren Besonderheiten beschrieben um dann auf Zwecke ei-
nes Bootloaders in seinen zwei Haupteinsatzgebieten zu erl¨
autern. Im Anschluss werden
schon bestehende L¨
osungen f¨
ur das in dieser Arbeit angegangene Problem betrachtet.
Zum Schluss werden zwei Dateiformate vorgestellt, in welchen die Software f¨
ur Sensor-
knoten nach einem Kompiliervorgang zur Verf¨
ugung stand.
2.1 Drahtlose Sensornetze
Bei drahtlosen Sensornetzen handelt es sich um Computernetze bestehend aus kleinen
Embedded-Ger¨
aten, welche ¨
uber verschiedene Stationen miteinander kommunizieren.
Diese Ger¨
ate sind in der Regel mit Sensoren f¨
ur verschiedenste Einsatzzwecke ausgestat-
tet und werden aufgrund ihrer Position im Computernetz als Sensorknoten bezeichnet.
Ein solcher Knoten basiert auf einem stromsparenden Microcontroller und besitzt einen
Sensor f¨
ur den eigentlichen Einsatzzweck sowie einen Transceiver Chip zur Kommunika-
tion ¨
uber die Luft.
In einem solchen Sensornetz k¨
onnen Knoten verschiedene Rollen einnehmen und je nach
Position im Netz verschiedene Aufgaben erf¨
ullen. In der Regel liefert ein Sensornetz
Messdaten an einen so genannten Host-PC zur persistenten Speicherung der Daten.
Damit diese Daten beim PC ankommen, wird oft ein Knoten mit der Aufgabe bedacht,
die gesammelten Daten aus dem Sensornetz ¨
uber eine serielle Kabelverbindung mit dem
PC auszutauschen. ¨
Uber diesen Master genannten Knoten k¨
onnen außerdem Daten in die
entgegengesetzte Richtung, n¨
amlich vom Host-PC zu einzelnen oder allen Sensorknoten
gesendet werden.
3
Die Kommunikation dieser Sensorknoten erfolgt ¨
uber ein MAC-Protokoll (Media-Access-
Control Protokoll). Dabei wird in den meisten F¨
allen nach einem bestimmten Verfahren
versucht sich mit den Nachbarknoten zu synchronisieren. Wurde diese Synchronisation
erreicht, findet die Kommunikation nur zu bestimmten Zeitpunkten statt und zwischen
diesen k¨
onnen die Knoten in einen Schlafmodus wechseln um Energie zu sparen.
Die Sensorknoten k¨
onnen sich dabei im Allgemeinen in verschiedenen Netzen organisie-
ren. Die einfachste M¨
oglichkeit ist, dass sich die Sensorknoten um einen Master-Knoten
herum in einer Sterntopologie organisieren (Abbildung 2.1). Auf diese Weise kommuni-
zieren alle Knoten direkt mit dem Master und leiten keine Daten f¨
ur andere Sensorknoten
weiter. Die Reichweite ist bei dieser Vernetzung jedoch begrenzt und ein Master muss
in der n¨
aheren Umgebung der Knoten vorhanden sein. Die Realisierung eines solchen
Netzes ist sehr einfach und die Software-Implementierung ist im Vergleich zu anderen
Topologien mit wenig Aufwand verbunden.
Abbildung 2.1:
Sterntopologie
Eine Vernetzungstopologie mit gr¨
oßerer Reichweite bietet die Baumtopologie wie in Ab-
bildung 2.2. Auf diese Weise besitzt ein Knoten immer einen direkten Vorg¨
anger, welcher
in der ersten Stufe der Master-Knoten ist. Sensorknoten k¨
onnen vom Master-Knoten
physisch weiter entfernt sein als bei der Sterntopologie, da die Kommunikation mit dem
Master ¨
uber die jeweiligen Vorg¨
angerknoten weitergeleitet wird. Diese Art der Vernet-
zung ist schon um einiges aufw¨
andiger zu realisieren und erfordert Ausfallstrategien
falls ein Vorg¨
angerknoten nicht mehr zur Verf¨
ugung stehen w¨
urde. Bei solchen Netzen,
¨
uber welche die Kommunikation mehrere Knoten stattfindet, spricht man auch von so
genannten Multi-Hop Networks.
4
Abbildung 2.2:
Baumtopologie
Bei einem vermaschten Sensornetz (Abbildung 2.3) hingegen sind die Knoten nicht nur
direkt mit einem Vorg¨
anger verbunden, sondern k¨
onnen mit jedem erreichbaren Sensor-
knoten kommunizieren. Der Vorteil eines solchen Netzes ist, dass die Kommunikation
nicht nur ¨
uber einen bestimmten Vorg¨
anger stattfindet und somit bei Ausfall eines be-
stimmten Knoten die Kommunikationsf¨
ahigkeit recht einfach aufrecht erhalten werden
kann. Die Nachteile dieser Netztopologie sind allerdings, dass diese ein aufw¨
andiges Rou-
tingverfahren voraussetzen und ein h¨
oheres Kommunikationsaufkommen entsteht.
Abbildung 2.3:
Vermaschtes Netz
Die Tiefe eines Sensornetzes beschreibt die Anzahl der Stationen ¨
uber welche die Kom-
munikation bis zum Ende hin stattfindet. Bei der Breite dagegen handelt es sich um die
maximale Anzahl von Knoten auf den jeweiligen Tiefenebenen. Bei einer Sterntopologie
betr¨
agt die Tiefe demnach also immer 2 und die Breite die Anzahl der Sensorknoten oh-
ne den Master. Bei der in Abbildung 2.2 dargestellten Baumtopologie betr¨
agt die Tiefe
3 und die Breite 4.
5
Das Fraunhofer Institut f¨
ur Integrierte Schaltungen (IIS) arbeitet an einer eigenen Hard-
und Software Implementierung f¨
ur solche drahtlosen Sensornetze. Die Hardware wird
als Sensorknoten S1 bezeichnet, w¨
ahrend die Software als das Betriebssystem MuTa
entwickelt wird und Slotted-MAC den Zugriff der Sensorknoten auf die Luftschnittstelle
als Zugriffsschicht regelt. Die gesamte Plattform, bestehend aus Hard- und Software,
wird umfassend in Kapitel 3 vorgestellt.
2.2 Bootloader
Ein Bootloader ist ¨
ublicherweise das erste Programm das auf einem Computersystem
nach der Hardware Initialisierung gestartet wird und ist daf¨
ur verantwortlich das eigent-
liche Hauptprogramm (zum Beispiel ein Betriebssystem) zu laden und ihm die Kontrolle
¨
uber das System zu geben. Je nach Einsatzzweck k¨
onnen sich die Aufgaben eines Boot-
loaders jedoch etwas unterscheiden.
2.2.1 PC Bootloader
Auf einem herk¨
ommlichen PC dient ein Bootloader vor allem dem Start eines Betriebs-
systems und zur Auswahl dessen, falls mehrere davon auf einem Computer installiert
sind. Dieser wird im Master Boot Record (MBR) der Festplatte installiert; einem Be-
reich der speziell f¨
ur diese Zwecke eingef¨
uhrt wurde und von der PC Hardware nach
der Initialisierung gezielt ausgef¨
uhrt wird. Ein Beispiel f¨
ur einen solchen Bootloader ist
GNU GRUB [gru]. Dieser bietet Unterst¨
utzung f¨
ur alle g¨
angigen Betriebssysteme die
auf dem PC installiert werden k¨
onnen und wird von einigen freien
1
Betriebssystemen als
Standard-Bootloader installiert. Ein solcher Bootloader dient jedoch nur diesem Zweck
und bietet keine M¨
oglichkeiten andere Aufgaben damit zu erledigen, da dies dem zu star-
tenden Betriebssystem oder Spezialsoftware (zum Beispiel memtest86 f¨
ur Speichertests)
¨
uberlassen wird.
1
Als freies Betriebssystem ist hier ein System gemeint, dessen Quellcode offen gelegt ist
6
2.2.2 Eingebettete Systeme
Auf einem eingebetteten System, wie dem in den folgenden Kapiteln beschriebenen, wer-
den jedoch andere Aufgaben von einen Bootloader ¨
ubernommen. So ist es un¨
ublich, dass
mehrere Betriebssysteme auf einem solchen Ger¨
at installiert sind, wenn ¨
uberhaupt ein
Betriebssystem als solches verwendet wird. Oft befinden sich einfache Anwendungen die
nur f¨
ur einen Einsatzzweck entwickelt wurden auf solchen Ger¨
aten. Der Vorteil dieser
ist, dass die Anwendungen auf diese Weise wenig Overhead durch ein f¨
ur allgemeinere
Aufgaben ausgelegtes Betriebssystem haben und weniger des ohnehin gering bemessenen
Speichers und der knappen Ressourcen wie Arbeitsspeicher und CPU-Leistung verwen-
den.
Der große Unterschied gegen¨
uber einem PC-Bootloader ist, dass ein Bootloader auf
einem eingebetteten System weitreichendere Aufgaben ¨
ubernimmt als verschiedene Be-
triebssysteme zur Auswahl anzubieten und diese dann zu starten. Da der Bootloader
unabh¨
angig vom letztlich zu startenden Betriebssystem oder der Anwendung ist, kann
er dazu verwendet werden genau diesen auf dem System installierten Code zu verwalten
und gegebenenfalls neu zu schreiben. Dazu ist es jedoch n¨
otig, dass der Programmspei-
cher des Ger¨
ates von der Hardware durch ausgef¨
uhrten Programmcode neu beschrieben
werden kann. Um das Schreiben einer Anwendung die den kompletten verf¨
ugbaren Spei-
cherplatz einnimmt zu erm¨
oglichen ist es außerdem notwendig, dass ein zus¨
atzlicher
Speicher zur Verf¨
ugung steht der ein Firmware-Image aufnehmen kann. Dies ist in vie-
len F¨
allen ein EEPROM (Electrically Erasable Programmable Read Only Memory) der
einem Mikrocontroller oder Mikrocomputer zur Seite gestellt wird.
2.3 Bestehende Bootloader-Implementierungen
Da Mikrocontroller schon seit einiger Zeit in diversen Einsatzgebieten zu finden sind, gibt
es schon bestehende Ans¨
atze und L¨
osungen f¨
ur die Problemstellung eines Bootloaders im
Embedded Bereich. Es gibt einerseits viele verschiedene Bootloader Implementierungen
die auf eine spezielle Aufgabe in einem Unternehmen oder im privaten Bereich aus-
gerichtet sind, wor¨
uber es jedoch kaum aussagekr¨
aftige ¨
offentliche Informationen und
Dokumentation gibt. Andererseits gibt es aber auch Implementierungen die f¨
ur den
allgemeinen Einsatzzweck gedacht sind und zwei davon werden in den nachfolgenden
Abschnitten n¨
aher beschrieben. Zuerst werden die speziellen Bootloader F¨
ahigkeiten des
7
Atmel AVR Mikrocontroller und darauffolgend das Softwareverteilungssystem f¨
ur draht-
lose Sensornetze Deluge betrachtet.
2.3.1 Atmel AVR Mikrocontroller
Es gibt viele verschiedene Mikrocontroller die im Bereich der drahtlosen Sensornetze
eingesetzt werden und einer davon ist der AVR von Atmel [avr] mit einer 8-Bit oder
16-Bit RISC CPU. Er verf¨
ugt als Mikrocontroller ¨
uber Timer, eine USART (Universal
Synchronous/Asynchronous Receiver Transmitter) und Analog/Digital- sowie Digital/A-
nalog-Wandler. Der AVR kann in mehrere Modi mit geringem Stromverbrauch versetzt
werden, bei welchen die Spannung und die Funktionalit¨
at jeweils reduziert wird.
Einige Modelle des AVR bieten besondere Unterst¨
utzung f¨
ur einen Bootloader [Sch06] im
auf dem Chip integrierten Flash-Speicher, welcher normalerweise nur f¨
ur die Anwendung
vorgesehen ist. Diese Unterst¨
utzung beinhaltet das Sperren eines f¨
ur den Bootloader re-
servierten Speicherbereichs und die gesonderte Behandlung von Interrupts. Die Interrupt
Vektor Tabelle ist am Anfang des Flash-Speichers, welcher mit der Adresse 0x0000 be-
ginnt, platziert. Die Abbildung 2.4 zeigt die allgemeine Speicheraufteilung des AVR,
wenn die Bootloader-Funktionalit¨
at nicht verwendet wird.
Abbildung 2.4:
Speicheraufteilung des Atmel AVR
Wird der Bootloader jedoch verwendet, so wird am Ende des Flash-Speichers ein Spei-
cherbereich reserviert und je nach Konfiguration gegen Schreibzugriffe gesch¨
utzt. In die-
8
sem Bereich kann dann der Bootloader unabh¨
angig von der im restlichen Speicherbe-
reich untergebrachten Anwendung platziert werden. Wie groß der reservierte Bereich ist,
h¨
angt davon ab wie die BOOTSZ0- und BOOTSZ1-Flags des Mikrocontrollers konfigu-
riert werden. In Tabelle 2.1 sind die verschiedenen Gr¨
oßen in Abh¨
angigkeit der beiden
Flags aufgelistet.
BOOTSZ1
BOOTSZ0
Gr¨
oße des Bootloader-Bereichs
1
1
128 W¨
orter
1
0
256 W¨
orter
0
1
512 W¨
orter
0
0
1024 W¨
orter
Tabelle 2.1:
M¨
ogliche Gr¨
oßen des AVR Bootloaders
Eine Funktionalit¨
at die bei der Implementierung eines Bootloaders besonders hilfreich
ist, ist die M¨
oglichkeit die Platzierung der Reset-Adresse und der restlichen Interrupt
Vektoren zu ver¨
andern. In Tabelle 2.2 werden die verschiedenen M¨
oglichkeiten zur Ver-
teilung aufgezeigt. Die Bootloader Reset Adresse errechnet sich aus der Gr¨
oße des Flash-
Speichers (
flashsize) im Mikrocontroller und der Gr¨oße des Bootloaders (bootsize)
durch
flashsize-bootsize. F¨ur die Platzierung m¨ussen die Flags BOOTRST und IVSEL
ge¨
andert werden.
BOOTRST
IVSEL
Reset Adresse
Interrupt Vektoren
1
1
0x0000
0x0000 + 1 Wort
1
0
0x0000
Bootloader Reset + 1 Wort
0
1
Bootloader Reset
0x0000 + 1 Wort
0
0
Bootloader Reset
Bootloader Reset + 1 Wort
Tabelle 2.2:
M¨
ogliche Platzierungen der Interrupts beim AVR
Damit sind verschiedene M¨
oglichkeiten zur Integration eines Bootloaders gegeben. Die
am h¨
aufigsten eingesetzte Variante ist, den Reset Vector auf den Bootloader zeigen zu
lassen und die restlichen Interrupt Vektoren auf den Anwendungs-Code, da in der Regel
keine Interrupts im Bootloader verwendet werden. Da jedoch bereits eine bestehende, auf
dem MSP430 Mikrocontroller basierende Sensorknotenplattform am Fraunhofer Institut
eingesetzt wird, musste eine ¨
ahnliche Funktionalit¨
at selbst implementiert werden und
wird in Kapitel 4 beschrieben.
9
2.3.2 Deluge Softwareverteilungssystem
Eine in Software entwickelte Umsetzung f¨
ur die ¨
Ubetragung und Programmierung von
Firmware Images f¨
ur Sensorknoten ist das Softwareverteilungssystem Deluge in Kom-
bination mit dem Bootloader TOSBoot. Diese Anwendungen wurden f¨
ur das TinyOS
Betriebssystem, welches speziell f¨
ur die Nutzung in drahtlosen Sensornetzen konzipiert
ist, entwickelt. Dieses Gesamtsystem ist f¨
ur den allgemeinen Einsatz gedacht und geht
nicht auf spezielle Bed¨
urfnisse im Einzelnen ein. Ein Einsatz dieser Software auf der
Plattform des Fraunhofer Instituts ist aufgrund der Verwendung eines eigenen Betriebs-
systems jedoch nicht vorgesehen (siehe Kapitel 3). Allerdings liefert das Gesamtkonzept
dieser L¨
osung wie die Hardware des AVR Mikrocontrolers Ideen, welche in das resultie-
rende Konzept dieser Arbeit ¨
ubernommen wurden.
TinyOS Betriebssystem
TinyOS [tin] ist ein h¨
aufig eingesetztes Open-Source Betriebssystem, welches ausschließ-
lich f¨
ur den Einsatz auf Sensorknoten in drahtlosen Sensorknoten entwickelt wurde. Es
bietet von Haus aus Unterst¨
utzung f¨
ur die drahtlose Kommunikation, mit einer Im-
plementierung der Bit¨
ubertragungs- sowie Sicherungsschicht nach dem IEEE 802.15.4
Standard. Damit lassen sich Multihop-Netze realisieren, bei welchen Daten in einem
Netz mit Baum-Topologie ¨
uber mehrere Knoten hinweg versendet werden k¨
onnen. Bei
einer Baum-Topologie m¨
ussen Knoten mit Router-Funktionalit¨
at im Netz vorhanden
sein, sonst ist nur eine Stern-Topolgie ohne Multihop-F¨
ahigkeiten m¨
oglich. Ein so ge-
nannter Coordinator, der ¨
ublicherweise an eine dauerhafte Stromquelle angeschlossen ist,
¨
ubernimmt die Kommunikation mit dem Host-PC, in welchem die gesammelten Daten
der Sensorknoten verarbeitet werden.
TinyOS selbst und Anwendungen f¨
ur dieses Betriebssystem werden in der Program-
miersprache nesC entwickelt. Diese ist eine Weiterentwicklung von C mit verschiedenen
Erweiterungen, die eine Programmierung f¨
ur Embedded Ger¨
ate vereinfachen sollen. Ein
solches TinyOS Programm besteht aus verschiedenen Komponenten, welche ¨
uber Er-
eignisse und Kommandos miteinander kommunizieren. Die Interaktion geschieht dabei
¨
uber klar definierte Schnittstellen, welche von einer Komponente bereitgestellt werden
m¨
ussen um dann von anderen Komponenten genutzt zu werden.
10
Deluge
Deluge [del] sorgt f¨
ur die sichere ¨
Ubertragung eines Firmware Images an die im Sen-
sornetz verteilten Knoten unter Ber¨
ucksichtigung der bei solchen Netzen gegebenen
Anforderungen [CHT]. Es besteht aus einer Anwendung f¨
ur TinyOS, welche auf dem
Sensorknoten installiert wird, sowie aus einer in Java geschriebenen Software f¨
ur den
Host-PC, welche die Steuerung der Softwareverteilung und die initiale Einrichtung eines
Sensorknotens ¨
ubernimmt.
Deluge ist nicht auf einzelne Firmware-Images beschr¨
ankt und kann mehrere davon ver-
walten. Als Absicherung f¨
ur fehlerhafte Firmware-Images kann auf den Sensorknoten ein
so genanntes Golden Image abgelegt werden, welches jedoch dann einen der vorgesehe-
nen Pl¨
atze f¨
ur Firmware-Images belegt. Dieses bietet außer der M¨
oglichkeit ein Firmware
Image mittels Deluge zu empfangen keine weitere Funktionalit¨
at. Damit es jedoch nicht
ungewollt ¨
uberschrieben wird, kann das Golden Image gegen Schreibzugriffe gesch¨
utzt
werden, sofern die Hardware dies unterst¨
utzt. Um in einem Sensornetz die F¨
ahigkeiten
von Deluge nutzen zu k¨
onnen muss die Anwendungssoftware, welche den eigentlichen
Zweck des Sensornetzes erf¨
ullen soll, so angepasst werden, dass es das Deluge Interface
benutzt [Hui05].
Die PC-Software bedient nach der Initialisierung mit einem Deluge-f¨
ahigen Image nicht
mehr einzelne Knoten, sondern immer das gesamte Sensornetz. So f¨
uhrt die Installation
(Injection) eines neuen Firmware-Image mittels der Steuerungs-Software ¨
uber den Coor-
dinator dazu, dass das Image im gesamten Netz verteilt wird. Es wird davon ausgegan-
gen, dass alle Knoten die gleiche Anzahl und den gleichen Stand an Firmware-Images
verwalten. Wird ¨
uber die Steuerungs-Software ein neues Image zur Nutzung auf den
Knoten ausgew¨
ahlt, so beginnen alle Knoten im Netz die Neuprogrammierung mit der
ausgew¨
ahlten Firmware.
TOSBoot
TOSBoot ist eine v¨
ollig eigenst¨
andige TinyOS Anwendung zur Programmierung eines
Sensorknotens mit einem Firmware-Image, welches von Deluge zur Verf¨
ugung gestellt
wird. Dieser Bootloader bietet verschiedene Mechanismen um den Programmiervorgang
gegen¨
uber verschiedenen Fehlerquellen abzusichern:
11
CRC-Pr¨
ufsumme Bevor ein Firmware-Image in den Anwendungsspeicher eines Sensor-
knoten geschrieben wird, wird eine Pr¨
ufung des Images mit dem CRC-Pr¨
ufsum-
men-Verfahren durchgef¨
uhrt. Die Pr¨
ufsumme wird von Deluge zur Verf¨
ugung ge-
stellt.
Versorgungsspannung Um einen Schreibabbruch durch ungen¨
ugende Versorgung mit
Strom zu verhindern, wird vor einem m¨
oglichen Wechsel der Firmware ¨
uberpr¨
uft,
ob die Versorgungsspannung ausreichend ist.
¨
Uberschreibungsschutz Da nicht jede Hardware wie der AVR Mikrocontroller einen
Schutz f¨
ur einen Bootloader bietet und TinyOS auf verschiedenster Hardware
lauff¨
ahig ist, pr¨
uft TOSBoot deshalb jeweils ob ein Schreibvorgang in dem Be-
reich stattfinden w¨
urde, wo der Bootloader selbst platziert ist.
Reset-Z¨
ahler Mit jedem Versuch die Firmware eines Sensorknoten zu aktualisieren wird
ein Z¨
ahler um den Wert Eins erh¨
oht. Der Z¨
ahler wird nur auf Null zur¨
uck gesetzt,
wenn ein Update-Vorgang erfolgreich abgeschlossen wurde. Erreicht der Z¨
ahler
jedoch einen kritischen Wert, wird versucht das Golden-Image auf dem Sensorkno-
ten zu installieren um ein neues Firmware Image aus dem Sensornetz beziehen zu
k¨
onnen.
2.4 Dateiformate
Ein Firmware-Image stellt ein Abbild des auf einem Embedded-Ger¨
at lauff¨
ahigen Pro-
grammcodes dar, welcher aus Befehlen und Daten f¨
ur einen spezielle Prozessor besteht.
Ein solcher Befehl wird auch als Opcode bezeichnet und entspricht einer Zahl, die vom
jeweiligen Prozessor interpretiert wird und dann je nach Zahl eine Operation ausf¨
uhrt.
Jedem dieser Opcodes ist zur einfacheren Programmierung ein sogenanntes Mnemonic
(eine textuelle Bezeichnung f¨
ur einen Opcode) gegen¨
ubergestellt und aus diesen Mne-
monics bildet sich die jeweilige Assembler-Sprache f¨
ur einen Prozessor.
Um mit einem Firmware-Image auf einem Host-PC arbeiten zu k¨
onnen, w¨
are eine reine
Bin¨
ar-Darstellung des Opcodes ungeeignet, da sie sich vom Menschen schlecht oder nur
mit einem Hex-Editor oder ¨
Ahnlichem lesen l¨
asst. Genauso wenig eignet sich Assembler-
Code, da dieser erst in eine vom Prozessor lesbare Form umgesetzt werden m¨
usste und
eine direkte Kenntnis des Prozessorbefehlsatzes voraussetzt. Außerdem ist es notwendig
12