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

Inhaltsverzeichnis

1 Einleitung

2 Allgemeine Grundlagen
2.1 Drahtlose Sensornetze
2.2 Bootloader
2.2.1 PC Bootloader
2.2.2 Eingebettete Systeme
2.3 Bestehende Bootloader-Implementierungen
2.3.1 Atmel AVR Mikrocontroller
2.3.2 Deluge Softwareverteilungssystem
2.4 Dateiformate
2.4.1 TI TXT
2.4.2 Intel HEX

3 Sensorknoten Plattform
3.1 Hardware
3.1.1 Adressraum des MSP
3.1.2 Evaluation-Board
3.1.3 Speichermöglichkeiten
3.2 Software der Sensorknoten
3.2.1 MuTa Betriebssystem
3.2.2 Vernetzung der Sensorknoten
3.3 Entwicklungsumgebung

4 Konzeption
4.1 Anforderungen an den Bootloader
4.2 Bootloader Fähigkeiten des MSP
4.3 Aufteilung der Funktionalität
4.4 Ablauf eines Firmware Updates
4.5 Rollenverteilung
4.5.1 Funktion des Bootloaders
4.5.2 Aufgaben der Anwendung
4.5.3 Rolle des Host-PC
4.6 Sicherungsmechanismen
4.6.1 Spannungsversorgung des MSP430
4.6.2 Resets des MSP430
4.6.3 ÜberschreibendesBootloaders
4.6.4 Defekte Daten
4.7 Interrupt Weiterleitung
4.7.1 Feste Interrupt Vektor Tabelle im Flash-Speicher
4.7.2 Dynamische Interrupt Vektor Tabelle im RAM
4.8 Platzierung des Bootloaders im Speicher
4.8.1 Bootloader am Anfang ohne Interrupt Routing
4.8.2 Bootloader am Anfang mit Interrupt Routing
4.8.3 Bootloader am Ende mit Interrupt Routing
4.8.4 Bootloader am Ende ohne Interrupt Routing
4.8.5 Fazit
4.9 EEPROM Speicheraufteilung
4.9.1 Firmware-Image Verwaltung

5 Implementierung
5.1 Treiber
5.1.1 USART
5.1.2 SPI
5.1.3 EEPROM
5.1.4 Flash
5.2 Bootloader
5.2.1 Interrupt Handling
5.2.2 Bootloader API
5.3 Tool-Suite

6 Test
6.1 Probleme beim Test
6.2 Flash-Speicher Überprüfung
6.3 Test im Sensornetz
6.3.1 Testaufbauten
6.4 Testergebnisse

7 Zusammenfassung

Kurzfassung

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 In- stallationsvorgang 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 wer- den können. Die prototypische Implementierung realisiert die Teile des Konzepts, welche ohne ohne Kenntnis des endgültigen Aktualisierungsmechanismus (in Bezug auf Teilak- tualisierungsverfahren und Übertragungsmethodik) implementiert werden konnten.

Abstract

A steadily growing area of computer networking is the automated capturing of data with sensornodes. Those are small computer devices which can communicate over radio in a so called sensornetwork, work completely autarkic and are powered by batteries. The Fraunhofer Institute of Integrated Circuits works on an implementation of such devices and software. As with any technology in computer science the growing complexity of the software which runs on such devices causes a higher risk of software-bugs.

A bootloader concept and implementation to update software on sensornodes was developed within the work on this diploma thesis. The most important requirement was to assure that an update does not cause any harm on the device and that it can be booted into a known state everytime. The concept includes that several techniques have to be built to fulfill this requirement and that more than one firmware image can be stored and managed on the device. The implementation, which in fact is a prototype, only includes the basic parts of concept, as not everything could be implemented.

Erklärung

Ich erkläre hiermit, dass ich diese Diplomarbeit selbstständig angefertigt habe und dass alle Teile, die wörtlich oder inhaltlich aus anderen Quellen stammen, als solche kenntlich gemacht und in das Literaturverzeichnis aufgenommen wurden. Diese Arbeit wurde bei keiner anderen Prüfungsbehörde vorgelegt.

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
3.2 Adressraum des MSP430 F1611
3.3 Evaluation-Board für Sensorknoten
3.4 Beispiel einer Vernetzung mit Slotted-MAC
3.5 IAR Workbench

4.1 Ablauf eines Firmware Updates
4.2 Ablauf der Interrupt Verarbeitung mit fixem Interrupt-Routing
4.3 Bootloader am Anfang ohne Interrupt Routing
4.4 Bootloader am Anfang mit Interrupt Routing
4.5 Bootloader am Ende mit Interrupt Routing
4.6 Bootloader am Ende ohne Interrupt Routing
4.7 Speicheraufteilung des EEPROM
4.8 Verweis auf ein komplettes Firmware Image
4.9 Verweis auf Segmente für Teilaktualisierung

5.1 Kontrollfluss in spi write
5.2 Kontrollfluss beim Start des Bootloaders
5.3 Implementierte Speicheraufteilung des EEPROM
5.4 KOMBooterSuite

6.1 Debugger mit Flash-Speicher Ansicht
6.2 Testaufbauten

Tabellenverzeichnis

2.1 Mögliche Größen des AVR Bootloaders
2.2 Mögliche Platzierungen der Interrupts beim AVR
2.3 Intel Hex Format Zeilenaufbau

4.1 Einfacher Image Entry Aufbau
4.2 Erweiterter Image Entry Aufbau

6.1 Befehle der SMMART-Testanwendung

Listings

2.1 TI TXT Beispieldatei

2.2 Intel HEX Beispieldatei

5.1 usart init Signatur

5.2 USART Konfigurationsbeispiel

5.3 SPI Treiber API

5.4 SPI Beispiel

5.5 EEPROM Treiber API

5.6 Funktion eeprom write

5.7 EEPROM Beispiel

5.8 Flash Treiber API

5.9 Interrupt Beispiel

5.10 Konfigurationsdatei für den Linker

5.11 Dynamischer Interrupt Handler Beispiel

5.12 Interrupt Verarbeitung im Bootloader

5.13 Bootloader API in boot.h

1 Einleitung

Drahtlose Sensornetze sind ein Einsatzgebiet von Mikrocomputern welches in Zukunft eine bedeutende Rolle spielen wird und sich schon heute bewährt hat. Sie dienen dazu Daten in Bereichen zu erfassen, die keine feste Installation von Kommunikationswegen zulassen oder wo die benötigte Mobilität eine feste Verkabelung unmöglich macht, wie zum Beispiel bei der Lokalisierung von Waren in einem Lager. Der heutige Stand der Technik erlaubt es mit äußerst stromsparenden Mikroprozessoren und effizienten Kommunikationsverfahren, dass ein Datenerfassungssystem in einem drahtlosen Sensornetz, ein so genannter Sensorknoten, über Monate oder sogar Jahre hinweg ständig ohne Austausch der Energieversorgung völlig autark arbeiten kann.

Solche Systeme werden natürlich nicht nur als reine Hardware-Lösung hergestellt, son- dern besitzen eine spezielle, für einen bestimmten Einsatzzweck entwickelte, Software. Für eine Aktualisierung dieser Software ist es zwar möglich einen Sensorknoten an einen normalen Arbeits-PC anzuschließen, allerdings stört dies den laufenden Betrieb des Sen- sornetzes. Daher ist es sinnvoll eine Aktualisierung der Software für solche Sensorkno- ten über die bestehende Kommunikationsinfrastruktur des Sensornetzes anzustreben. Für diese Aktualisierungsmethode gibt es schon bestehende Lösungen für verschiedene Software- und Hardware-Systeme im Bereich der drahtlosen Sensornetze.

Das Fraunhofer Institut für Integrierte Schaltungen arbeitet an einer Implementierung eines eigenen Hard- und Software-Systems für drahtlose Sensornetze. Im Rahmen dieser Diplomarbeit sollte für einen integralen Bestandteil eines möglichen Aktualisierungme- chanismus dieser Sensorknotenplattform, nämlich 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öglichkeit im Kontext des Fraunhofer Systems überprüft. Bei der Erstellung des Konzepts wurde be- sonders darauf geachtet, dass die Implementierung eines Bootloaders im Rahmen der Möglichkeiten eine möglichst hohe Ausfallsicherheit bietet um so die Anforderung des autarken Betrieb des Sensornetzes zu unterstützen. Hierzu wurden veschiedene Mechanismen zur Sicherung der Betriebsfähigkeit des Sensorknoten entwickelt.

Die Implementierung selbst besteht zum großen Teil aus Treibern für die spezielle ver- wendete Hardware, einer Logik, welche die Verwaltung von Firmware-Images¹ über- 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ört die Überprüfung der Spannung und die Aktualisierungsroutine, welche die tatsächliche Aktualisierung der Sensorknoten-Software übernimmt. Um auch von einem Arbeits-PC aus die Aktualisierung über das Sensornetz vornehmen zu können, wurde ei- ne spezielle Software auf Basis der Eclipse Rich-Client-Plattform entwickelt. Die Eclipse RCP ermöglicht 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ätzlich für den Test des Bootloaders auf korrekte Funktion eine Übertragungsmöglichkeit für eine Software- Aktualisierung, basierend auf einer bestehenden Übertragungssoftware vom Fraunhofer Institut, implementiert werden. Diese prototypische Implementierung eines Bootloaders bildet am Ende die Basis für ein gesamtheitliches Aktualisierungsverfahren, welches um die fehlenden Teile, wie ein effizientes Übertragungsverfahren für Firmware-Images, er- weitert werden muss.

In den nachfolgenden Kapiteln 2 und 3 wird auf die allgemeinen und die für das Fraunhofer Institut spezifischen Grundlagen eingangen, um den Kontext näher zu erläutern. Das Kapitel 4 beschreibt die Konzeption der Aktualisierung aus Sicht des Bootloaders und dessen Funktionalität und Funktionsweise. Die tatsächliche Implementierung wird in Kapitel 5 vorgestellt und zeigt die erwähnte prototypische Umsetzung des Konzepts. Anschließend wird im 6. Kapitel auf die Probleme und Eigenheiten beim Test des Bootloaders eingegangen, bevor im 7. und letzten Kapitel eine Zusammenfassung einen Ausblick für die Zukunft des Bootloaders gibt.

2 Allgemeine Grundlagen

In diesem Kapitel wird auf die allgemeinen Grundlagen eingegangen und Begriffe eingeführt, die für das Verständnis der restlichen Kapitel notwendig sind. Zuerst werden drahtlose Sensornetze und deren Besonderheiten beschrieben um dann auf Zwecke eines Bootloaders in seinen zwei Haupteinsatzgebieten zu erläutern. Im Anschluss werden schon bestehende Lösungen für das in dieser Arbeit angegangene Problem betrachtet. Zum Schluss werden zwei Dateiformate vorgestellt, in welchen die Software für Sensorknoten nach einem Kompiliervorgang zur Verfügung stand.

2.1 Drahtlose Sensornetze

Bei drahtlosen Sensornetzen handelt es sich um Computernetze bestehend aus kleinen Embedded-Geräten, welche über verschiedene Stationen miteinander kommunizieren. Diese Geräte sind in der Regel mit Sensoren für 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ür den eigentlichen Einsatzzweck sowie einen Transceiver Chip zur Kommunika- tion über die Luft.

In einem solchen Sensornetz können Knoten verschiedene Rollen einnehmen und je nach Position im Netz verschiedene Aufgaben erfüllen. 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 über eine serielle Kabelverbindung mit dem PC auszutauschen. Über diesen Master genannten Knoten können außerdem Daten in die entgegengesetzte Richtung, nämlich vom Host-PC zu einzelnen oder allen Sensorknoten gesendet werden.

Die Kommunikation dieser Sensorknoten erfolgt über ein MAC-Protokoll (Media-Access- Control Protokoll). Dabei wird in den meisten Fällen 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önnen die Knoten in einen Schlafmodus wechseln um Energie zu sparen.

Die Sensorknoten können sich dabei im Allgemeinen in verschiedenen Netzen organisieren. Die einfachste Möglichkeit ist, dass sich die Sensorknoten um einen Master-Knoten herum in einer Sterntopologie organisieren (Abbildung 2.1). Auf diese Weise kommunizieren alle Knoten direkt mit dem Master und leiten keine Daten für andere Sensorknoten weiter. Die Reichweite ist bei dieser Vernetzung jedoch begrenzt und ein Master muss in der näheren 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 in dieser Leseprobe nicht enthalten

Abbildung 2.1: Sterntopologie

Eine Vernetzungstopologie mit größerer Reichweite bietet die Baumtopologie wie in Ab- bildung 2.2. Auf diese Weise besitzt ein Knoten immer einen direkten Vorgänger, welcher in der ersten Stufe der Master-Knoten ist. Sensorknoten können vom Master-Knoten physisch weiter entfernt sein als bei der Sterntopologie, da die Kommunikation mit dem Master über die jeweiligen Vorgängerknoten weitergeleitet wird. Diese Art der Vernet- zung ist schon um einiges aufwändiger zu realisieren und erfordert Ausfallstrategien falls ein Vorgängerknoten nicht mehr zur Verfügung stehen würde. Bei solchen Netzen, über welche die Kommunikation mehrere Knoten stattfindet, spricht man auch von so genannten Multi-Hop Networks.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Baumtopologie

Bei einem vermaschten Sensornetz (Abbildung 2.3) hingegen sind die Knoten nicht nur direkt mit einem Vorgänger verbunden, sondern können mit jedem erreichbaren Sensor- knoten kommunizieren. Der Vorteil eines solchen Netzes ist, dass die Kommunikation nicht nur über einen bestimmten Vorgänger stattfindet und somit bei Ausfall eines be- stimmten Knoten die Kommunikationsfähigkeit recht einfach aufrecht erhalten werden kann. Die Nachteile dieser Netztopologie sind allerdings, dass diese ein aufwändiges Rou- tingverfahren voraussetzen und ein höheres Kommunikationsaufkommen entsteht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Vermaschtes Netz

Die Tiefe eines Sensornetzes beschreibt die Anzahl der Stationen über 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ägt 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ägt die Tiefe 3 und die Breite 4.

Das Fraunhofer Institut für Integrierte Schaltungen (IIS) arbeitet an einer eigenen Hardund Software Implementierung für solche drahtlosen Sensornetze. Die Hardware wird als Sensorknoten S1 bezeichnet, während 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 üblicherweise das erste Programm das auf einem Computersystem nach der Hardware Initialisierung gestartet wird und ist dafür verantwortlich das eigentliche Hauptprogramm (zum Beispiel ein Betriebssystem) zu laden und ihm die Kontrolle über das System zu geben. Je nach Einsatzzweck können sich die Aufgaben eines Bootloaders jedoch etwas unterscheiden.

2.2.1 PC Bootloader

Auf einem herkömmlichen 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ür diese Zwecke eingeführt wurde und von der PC Hardware nach der Initialisierung gezielt ausgeführt wird. Ein Beispiel für einen solchen Bootloader ist GNU GRUB [gru]. Dieser bietet Unterstützung für alle gängigen Betriebssysteme die auf dem PC installiert werden können und wird von einigen freien¹ Betriebssystemen als Standard-Bootloader installiert. Ein solcher Bootloader dient jedoch nur diesem Zweck und bietet keine Möglichkeiten andere Aufgaben damit zu erledigen, da dies dem zu star- tenden Betriebssystem oder Spezialsoftware (zum Beispiel memtest86 für Speichertests) überlassen wird.

2.2.2 Eingebettete Systeme

Auf einem eingebetteten System, wie dem in den folgenden Kapiteln beschriebenen, wer- den jedoch andere Aufgaben von einen Bootloader übernommen. So ist es unüblich, dass mehrere Betriebssysteme auf einem solchen Gerät installiert sind, wenn überhaupt ein Betriebssystem als solches verwendet wird. Oft befinden sich einfache Anwendungen die nur für einen Einsatzzweck entwickelt wurden auf solchen Geräten. Der Vorteil dieser ist, dass die Anwendungen auf diese Weise wenig Overhead durch ein für 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über einem PC-Bootloader ist, dass ein Bootloader auf einem eingebetteten System weitreichendere Aufgaben übernimmt als verschiedene Be- triebssysteme zur Auswahl anzubieten und diese dann zu starten. Da der Bootloader unabhängig 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ötig, dass der Programmspei- cher des Gerätes von der Hardware durch ausgeführten Programmcode neu beschrieben werden kann. Um das Schreiben einer Anwendung die den kompletten verfügbaren Spei- cherplatz einnimmt zu ermöglichen ist es außerdem notwendig, dass ein zusätzlicher Speicher zur Verfügung steht der ein Firmware-Image aufnehmen kann. Dies ist in vie- len Fällen 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ätze und Lösungen für 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über es jedoch kaum aussagekräftige öffentliche Informationen und Dokumentation gibt. Andererseits gibt es aber auch Implementierungen die für den allgemeinen Einsatzzweck gedacht sind und zwei davon werden in den nachfolgenden Abschnitten näher beschrieben. Zuerst werden die speziellen Bootloader Fähigkeiten des Atmel AVR Mikrocontroller und darauffolgend das Softwareverteilungssystem für drahtlose 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ügt als Mikrocontroller über 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ät jeweils reduziert wird.

Einige Modelle des AVR bieten besondere Unterstützung für einen Bootloader [Sch06] im auf dem Chip integrierten Flash-Speicher, welcher normalerweise nur für die Anwendung vorgesehen ist. Diese Unterstützung beinhaltet das Sperren eines für den Bootloader reservierten Speicherbereichs und die gesonderte Behandlung von Interrupts. Die Interrupt Vektor Tabelle ist am Anfang des Flash-Speichers, welcher mit der Adresse 0x0000 beginnt, platziert. Die Abbildung 2.4 zeigt die allgemeine Speicheraufteilung des AVR, wenn die Bootloader-Funktionalität nicht verwendet wird.

Abbildung in dieser Leseprobe nicht enthalten

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ützt. In die sem Bereich kann dann der Bootloader unabhängig von der im restlichen Speicherbe- reich untergebrachten Anwendung platziert werden. Wie groß der reservierte Bereich ist, hängt davon ab wie die BOOTSZ0- und BOOTSZ1-Flags des Mikrocontrollers konfigu- riert werden. In Tabelle 2.1 sind die verschiedenen Größen in Abhängigkeit der beiden Flags aufgelistet.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1: Mögliche Größen des AVR Bootloaders

Eine Funktionalität die bei der Implementierung eines Bootloaders besonders hilfreich ist, ist die Möglichkeit die Platzierung der Reset-Adresse und der restlichen Interrupt Vektoren zu verändern. In Tabelle 2.2 werden die verschiedenen Möglichkeiten zur Ver- teilung aufgezeigt. Die Bootloader Reset Adresse errechnet sich aus der Größe des Flash- Speichers (f lashsize) im Mikrocontroller und der Größe des Bootloaders (bootsize) durch f lashsize − bootsize. Für die Platzierung müssen die Flags BOOTRST und IVSEL geändert werden.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.2: Mögliche Platzierungen der Interrupts beim AVR

Damit sind verschiedene Möglichkeiten zur Integration eines Bootloaders gegeben. Die am häufigsten 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 ähnliche Funktionalität selbst implementiert werden und wird in Kapitel 4 beschrieben.

2.3.2 Deluge Softwareverteilungssystem

Eine in Software entwickelte Umsetzung für dieÜbetragung und Programmierung von Firmware Images für Sensorknoten ist das Softwareverteilungssystem Deluge in Kom- bination mit dem Bootloader TOSBoot. Diese Anwendungen wurden für das TinyOS Betriebssystem, welches speziell für die Nutzung in drahtlosen Sensornetzen konzipiert ist, entwickelt. Dieses Gesamtsystem ist für den allgemeinen Einsatz gedacht und geht nicht auf spezielle Bedürfnisse 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ösung wie die Hardware des AVR Mikrocontrolers Ideen, welche in das resultie- rende Konzept dieser Arbeit übernommen wurden.

TinyOS Betriebssystem

TinyOS [tin] ist ein häufig eingesetztes Open-Source Betriebssystem, welches ausschließ- lich für den Einsatz auf Sensorknoten in drahtlosen Sensorknoten entwickelt wurde. Es bietet von Haus aus Unterstützung für die drahtlose Kommunikation, mit einer Im- plementierung der Bitübertragungs- sowie Sicherungsschicht nach dem IEEE 802.15.4 Standard. Damit lassen sich Multihop-Netze realisieren, bei welchen Daten in einem Netz mit Baum-Topologie über mehrere Knoten hinweg versendet werden können. Bei einer Baum-Topologie müssen Knoten mit Router-Funktionalität im Netz vorhanden sein, sonst ist nur eine Stern-Topolgie ohne Multihop-Fähigkeiten möglich. Ein so ge- nannter Coordinator, der üblicherweise an eine dauerhafte Stromquelle angeschlossen ist, übernimmt die Kommunikation mit dem Host-PC, in welchem die gesammelten Daten der Sensorknoten verarbeitet werden.

TinyOS selbst und Anwendungen für dieses Betriebssystem werden in der Programmiersprache nesC entwickelt. Diese ist eine Weiterentwicklung von C mit verschiedenen Erweiterungen, die eine Programmierung für Embedded Geräte vereinfachen sollen. Ein solches TinyOS Programm besteht aus verschiedenen Komponenten, welche über Ereignisse und Kommandos miteinander kommunizieren. Die Interaktion geschieht dabei über klar definierte Schnittstellen, welche von einer Komponente bereitgestellt werden müssen um dann von anderen Komponenten genutzt zu werden.

Deluge

Deluge [del] sorgt für die sichere ÜbertragungeinesFirmwareImagesandieimSen- sornetz verteilten Knoten unter Berücksichtigung der bei solchen Netzen gegebenen Anforderungen [CHT]. Es besteht aus einer Anwendung für TinyOS, welche auf dem Sensorknoten installiert wird, sowie aus einer in Java geschriebenen Software für den Host-PC, welche die Steuerung der Softwareverteilung und die initiale Einrichtung eines Sensorknotens übernimmt.

Deluge ist nicht auf einzelne Firmware-Images beschränkt und kann mehrere davon ver- walten. Als Absicherung für fehlerhafte Firmware-Images kann auf den Sensorknoten ein so genanntes Golden Image abgelegt werden, welches jedoch dann einen der vorgesehe- nen Plätze für Firmware-Images belegt. Dieses bietet außer der Möglichkeit ein Firmware Image mittels Deluge zu empfangen keine weitere Funktionalität. Damit es jedoch nicht ungewollt überschrieben wird, kann das Golden Image gegen Schreibzugriffe geschützt werden, sofern die Hardware dies unterstützt. Um in einem Sensornetz die Fähigkeiten von Deluge nutzen zu können muss die Anwendungssoftware, welche den eigentlichen Zweck des Sensornetzes erfüllen soll, so angepasst werden, dass es das Deluge Interface benutzt [Hui05].

Die PC-Software bedient nach der Initialisierung mit einem Deluge-fähigen Image nicht mehr einzelne Knoten, sondern immer das gesamte Sensornetz. So führt die Installation (Injection) eines neuen Firmware-Image mittels der Steuerungs-Software über 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 über die Steuerungs-Software ein neues Image zur Nutzung auf den Knoten ausgewählt, so beginnen alle Knoten im Netz die Neuprogrammierung mit der ausgewählten Firmware.

TOSBoot

TOSBoot ist eine völlig eigenständige TinyOS Anwendung zur Programmierung eines Sensorknotens mit einem Firmware-Image, welches von Deluge zur Verfügung gestellt wird. Dieser Bootloader bietet verschiedene Mechanismen um den Programmiervorgang gegenüber verschiedenen Fehlerquellen abzusichern:

CRC-Prüfsumme Bevor ein Firmware-Image in den Anwendungsspeicher eines Sensor- knoten geschrieben wird, wird eine Prüfung des Images mit dem CRC-Prüfsum- men-Verfahren durchgeführt. Die Prüfsumme wird von Deluge zur Verfügung ge- stellt.

Versorgungsspannung Um einen Schreibabbruch durch ungenügende Versorgung mit Strom zu verhindern, wird vor einem möglichen Wechsel der Firmware überprüft, ob die Versorgungsspannung ausreichend ist.

ÜberschreibungsschutzDanichtjedeHardwarewiederAVRMikrocontrollereinen Schutz für einen Bootloader bietet und TinyOS auf verschiedenster Hardware lauffähig ist, prüft TOSBoot deshalb jeweils ob ein Schreibvorgang in dem Be- reich stattfinden würde, wo der Bootloader selbst platziert ist.

Reset-Zähler Mit jedem Versuch die Firmware eines Sensorknoten zu aktualisieren wird ein Zähler um den Wert Eins erhöht. Der Zähler wird nur auf Null zurück gesetzt, wenn ein Update-Vorgang erfolgreich abgeschlossen wurde. Erreicht der Zähler 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önnen.

2.4 Dateiformate

Ein Firmware-Image stellt ein Abbild des auf einem Embedded-Gerät lauffähigen Pro- grammcodes dar, welcher aus Befehlen und Daten für 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ührt. Jedem dieser Opcodes ist zur einfacheren Programmierung ein sogenanntes Mnemonic (eine textuelle Bezeichnung für einen Opcode) gegenübergestellt und aus diesen Mne- monics bildet sich die jeweilige Assembler-Sprache für einen Prozessor.

Um mit einem Firmware-Image auf einem Host-PC arbeiten zu können, wäre eine reine Binär-Darstellung des Opcodes ungeeignet, da sie sich vom Menschen schlecht oder nur mit einem Hex-Editor oder Ähnlichem lesen lässt. Genauso wenig eignet sich Assembler- Code, da dieser erst in eine vom Prozessor lesbare Form umgesetzt werden müsste und eine direkte Kenntnis des Prozessorbefehlsatzes voraussetzt. Außerdem ist es notwendig die Platzierung des vom Assembler oder anderen Compilern generierten Opcodes zu wissen, um ein Firmware-Image auch an die richtige Position im Embedded-Gerät schreiben zu können. Für diesen Zweck wurden verschiedene lesbare Dateiformate entwickelt und zwei davon werden nachfolgend beschrieben.

2.4.1 TI TXT

Das TXT Format von Texas Instruments (TI) ist ein sehr einfaches Format welches die einzelnen Byte eines Firmware-Images als hexadezimale Werte in einer simplen Textdatei darstellt. Dabei kommen üblicherweise 16 Byte auf einer Zeile durch ein Leerzeichen getrennt vor. Zusätzlich ist es möglich die Adresse des gesamten Firmware-Images oder Teilen davon anzugeben, was durch eine einzelne Zeile der Form @ADDR erreicht wird. Am Ende der Datei muss eine Zeile mit q als einzigem Zeichen platziert werden. Eine Beispieldatei stellt Listing 2.1 dar.

Abbildung in dieser Leseprobe nicht enthalten

Listing 2.1: TI TXT Beispieldatei

2.4.2 Intel HEX

Das HEX Format von Intel bietet im Gegensatz zum etwas einfacheren TI TXT Format zusätzlich Prüfsummen und generell mehr Informationen zum Inhalt der Daten, was ei- ne Datei in diesem Format allerdings größer macht. Wie beim TI TXT Format werden die Daten als hexadezimale Werte dargestellt und üblich sind 16 oder 32 Byte auf einer Zeile. Die Adresse wird jedoch, neben anderen Angaben, auf jeder Zeile, welche mit dem Zeichen ≫: ≪ beginnt, angegeben. Dabei können verschiedene Zeilen unterschiedliche Ty- pen haben. In Tabelle 2.3 wird eine Zeile die Daten eines Firmware-Images repräsentiert genauer aufgeschlüsselt. Andere Zeilentypen können einen leicht anderen Aufbau haben und die wichtigsten Zeilentypen sind 00 für einen Datensatz und 01 für das Dateiende. In Listing 2.2 ist eine Beispieldatei für das Intel HEX Format aufgelistet.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.3: Intel Hex Format Zeilenaufbau

Abbildung in dieser Leseprobe nicht enthalten

Listing 2.2: Intel HEX Beispieldatei

3 Sensorknoten Plattform

Die im Rahmen dieser Diplomarbeit eingesetzte Sensorknoten-Plattform ist eine vollständige Eigenentwicklung des Fraunhofer Instituts für Integrierte Schaltungen. Sie besteht aus einem Sensorknoten auf Basis eines MSP430 Mikrocontrollers von Texas Instruments und einem eigens dafür entwickelten Betriebssystem mit dem Namen MuTa. In diesem Kapitel werden beide Teile näher beschrieben.

3.1 Hardware

Der Sensornoten (Abbildung 3.1) mit der Bezeichnung S1 basiert auf dem MSP430 Mi- krocontroller der Firma Texas Instruments (TI) in der Variante F1611. Diese Ausführung besitzt eine 16-Bit CPU mit 4 MHz Taktfrequenz, 10 KByte Arbeitsspeicher sowie 48 KByte Flash-Speicher. Der Mikrocontroller enthält außerdem zwei USART (Universal Synchronous/Asynchronous Receiver Transmitter) Schnittstellen, einen Watchdog Ti- mer, zwei Timer, einen Controller für den internen Flash-Speicher, 6 Digitale I/O-Ports mit jeweils 8 Bit (wobei einige doppelt mit anderer Hardware wie USART belegt sind), sowie jeweils einen 12-Bit und 10-Bit Analog/Digital Wandler und einen 12-Bit Digi- tal/Analog Wandler. Der Stromverbrauch kann durch verschiedene Stromsparmodi auf bis zu 2 μ A gesenkt werden.

Auf dem Sensorknoten befinden sich neben dem Mikrocontroller ein zusätzliches, aus Sicht des Mikrocontrollers externes EEPROM (Electrically Erasable Programmable Read Only Memory) sowie ein Transceiver vom Typ TI CC1100 zur Funkübertragung. Als Erweiterung kann ein Bewegungssensor auf dem Knoten installiert werden. Allgemein wurde die Plattform auf autarken Betrieb mit langer Laufzeit und niedrigem Energieverbrauch ausgelegt, was durch den äußerst sparsamen Mikrocontroller und die verwendete Software (siehe Abschnitt 3.2) erreicht wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1: Sensorknoten S1, Originalmaße: 3,6cm x 8,5cm x 0,5cm

3.1.1 Adressraum des MSP430

Der Adressraum des 16-Bit Mikrocontrollers umfasst 64 KByte und ist wie es in Ab- bildung 3.2 dargestellt wird aufgeteilt. Der Adressbereich 0x4000 - 0xFFFF zeigt auf den im Mikrocontroller enthaltenen Flash-Speicher. Die obersten 32 Byte von Adresse 0xFFE0 bis 0xFFFF enthalten 16 jeweils 2 Byte große Wörter mit Vektoren, die auf Interrupt Service Routinen (ISR) zeigen. Im Adressbereich 0x4000 bis 0xFFDF wird der Anwendungscode platziert, welcher vom Mikrocontroller ausgeführt werden soll. Dieser Flash-Speicher lässt sich beliebig neu beschreiben und wird in Abschnitt 3.1.3 näher beschrieben. Der frei verfügbare und flüchtige Arbeitsspeicher ist bei dem verwendeten Modell des Mikrocontrollers 10 KByte groß und in den Adressbereich 0x1100 bis 0x38FF eingeblendet. In den untersten Adressbereich sind die Peripherie wie I/O-Ports, Timer etc. eingeblendet. Dabei sind im Bereich 0x00 bis 0x0F Special Function Register, im Bereich 0x10 bis 0xFF 8 Bit Hardware (zum Beispiel I/O Ports) und im Bereich 0x100 bis 0x1FF die 16 Bit Hardware (zum Beispiel Timer) adressierbar.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.2: Adressraum des MSP430 F1611

3.1.2 Evaluation-Board

Zur Programmierung des Sensorknotens wird ein so genanntes Evaluation-Board (Abbildung 3.3) eingesetzt, auf welchem ein Sensorknoten montiert werden kann. Der Sensorknoten kann dann über einen USB-Anschluss vom PC aus, der mit dem Evaluation Board verbunden ist, programmiert werden. Dazu wird der im MSP430 integrierte BootstrapLoader benutzt, welcher in einem ROM im Mikrocontroller untergebracht ist. Dieser ermöglicht es den integrierten Flash-Speicher des Sensorknoten zu löschen und dort hinein ein neues Firmware-Image zu schreiben. Weiterhin bietet das Evaluation-Board einen Anschluss für den JTAG-Debugger um damit das Verhalten des Mikrocontrollers direkt auf der Hardware zu untersuchen und Fehler zu finden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.3: Evaluation-Board für Sensorknoten

Der MSP430 selbst sieht keinen Bootloader im Programmspeicher vor und bietet daher keinerlei Unterstützung, wie zum Beispiel besonderes Interrupt Handling oder das Si- chern bestimmter Code-Bereiche gegenüber Schreibzugriffen (siehe Unterabschnitt 2.3.1). Eine Nutzung des integrierten Bootstrap-Loader für die angestrebten Zwecke ist nicht möglich, da dieser nur Daten von einer seriellen Schnittstelle lesen kann (siehe Ab- schnitt 3.1.3).

3.1.3 Speichermöglichkeiten

MSP430 Flash-Speicher

Der auf dem Sensorknoten eingesetzte Mikrocontroller verfügt über einen integrierten Flash-Speicher der gelöscht und wieder beschrieben werden kann. Der Hauptteil des Speichers ist in 512 Byte große Segmente unterteilt die einzeln gelöscht werden können. Das Löschen einzelner Bytes oder Wörter ist jedoch nicht möglich. Nachdem ein Seg- ment gelöscht wurde, lassen sich in diesem Bereich erneut einzelne Daten im Byte- oder Wort- Adressierungsmodus schreiben. In den nachfolgenden Unterabschnitten werden die verschiedenen Möglichkeiten den Flash-Speicher zu ändern beschrieben.

[...]

---

¹ Programm-Code, welcher auf einem bestimmten Gerät ausgeführt werden kann

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