Entwurf und Implementierung eines Bootloader-Konzepts. Programmierung eines Embedded Systems auf Basis der Texas Instruments MSP430 Mikrocontroller Familie

Salzwedel, Sven

Titel: Entwurf und Implementierung eines Bootloader-Konzepts. Programmierung eines Embedded Systems auf Basis der Texas Instruments MSP430 Mikrocontroller Familie

Entwurf und Implementierung eines Bootloader-Konzepts. Programmierung eines Embedded Systems auf Basis der Texas Instruments MSP430 Mikrocontroller Familie

Zusammenfassung

Ein in Zukunft an Bedeutung stark zunehmender Bereich der Computernetze ist die automatisierte mobile Datenerfassung mittels Sensorknoten, welche batteriebetrieben und völlig autark in einem drahtlosen Sensornetz zu verschiedenen Zwecken eingesetzt werden können. Das Fraunhofer Institut für Integrierte Schaltungen arbeitet selbst an einer proprietären Implementierung solcher Sensorknoten und der dazugehörigen Software. Wie in den meisten Bereichen der Informatik steigt mit zunehmenden Möglichkeiten die Komplexität der Software auf den Geräten, was zwangsläufig dazu führt, dass in der Software verstärkt Fehler auftreten können.
Im Rahmen dieser Diplomarbeit wurde ein Konzept und eine Implementierung eines Bootloaders entwickelt, welcher eine Aktualisierung der Software dieser Sensorknoten ermöglicht. Dabei wurde auf die Anforderung, größtmögliche Ausfallsicherheit beim Installationsvorgang eines Firmware-Images zu gewährleisten, eingegangen. Das Konzept sieht vor, dass verschiedene Sicherungsmechanismen einen unbenutzbaren Sensorknoten verhindern sollen und mehrere Firmware-Images auf dem Sensorknoten verwaltet werden können. Die prototypische Implementierung realisiert die Teile des Konzepts, welche ohne ohne Kenntnis des endgültigen Aktualisierungsmechanismus (in Bezug auf Teilaktualisierungsverfahren und Übertragungsmethodik) implementiert werden konnten.

Leseprobe

Inhaltsverzeichnis

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

Implementierung

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

Test

6.1

Probleme beim Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.2

Flash-Speicher ¨

Uberpr¨

ufung . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.3

Test im Sensornetz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.3.1

Testaufbauten

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.4

Testergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Zusammenfassung

iii

Abbildungsverzeichnis

2.1

Sterntopologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2

Baumtopologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3

Vermaschtes Netz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.4

Speicheraufteilung des Atmel AVR . . . . . . . . . . . . . . . . . . . . . .

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

Tabellenverzeichnis

2.1

M¨

ogliche Gr¨

oßen des AVR Bootloaders . . . . . . . . . . . . . . . . . . . .

2.2

M¨

ogliche Platzierungen der Interrupts beim AVR . . . . . . . . . . . . . .

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

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

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

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

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.

Programm-Code, welcher auf einem bestimmten Ger¨

at ausgef¨

uhrt werden kann

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.

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.

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.

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

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.

Als freies Betriebssystem ist hier ein System gemeint, dessen Quellcode offen gelegt ist

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

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-

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

128 W¨

orter

256 W¨

orter

512 W¨

orter

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

0x0000

0x0000 + 1 Wort

0x0000

Bootloader Reset + 1 Wort

Bootloader Reset

0x0000 + 1 Wort

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.

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.

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:

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

Details

Seiten

Erscheinungsform

Erstausgabe

Jahr

2008

ISBN (PDF)

9783959935159

ISBN (Paperback)

9783959930154

Dateigröße

2.3 MB

Sprache

Deutsch

Institution / Hochschule

Hochschule Coburg (FH) – Informatik

Erscheinungsdatum

2016 (September)

Note

1,0

Schlagworte

mobile Datenerfassung Sensorknoten Firmware-Image prototypische Implementierung Bootloader

Autor

Sven Salzwedel (Autor:in)