Programmieren und Testen
Upgraden von MSP430-Firmware per USB

Die Einführung neuer MSP430-Bausteine mit USB-Funktion eröffnet die reizvolle Perspektive, Firmware-Downloads oder Upgrades künftig per USB vorzunehmen. Dies hat zahlreiche Vorteile: Es wird keine separate JTAG-Verbindung benötigt, die Programmierung läuft schneller ab und das Programmieren und Testen des Bausteins ist ohne Entnahme aus der Schaltung möglich. Nicht zuletzt besteht die Möglichkeit, Firmware-Updates direkt an die Endanwender zu verbreiten, da lediglich ein PC und ein USB-Kabel notwendig sind, um Upgrades einzuspielen.
Möglich wird all dies mit dem eingebauten USB-basierten Bootstrap Loader (BSL) der Geräte. Dieser erlaubt Firmware-Upgrades mithilfe einer Reihe standardisierter Befehle, die u.a. zum Löschen, Programmieren und Verifizieren der Firmware dienen. Der zum standardmäßigen Lieferumfang gehörende USB-BSL wird automatisch aufgerufen, sobald ein unprogrammiertes Gerät per USB eingeschaltet wird oder wenn der PUR-Pin mit VUSB verbunden wird. Die zweite Option ermöglicht ein Aufrufen des BSL per Tastendruck für den Fall, dass die Firmware eines Geräts nicht mehr intakt ist. Wenn es notwendig ist, beim Einschalten des Geräts eine bestimmte Taste gedrückt zu halten, so beeinträchtigt dies die Nutzererfahrung, zumal dazu nicht selten ziemliche Verrenkungen gemacht werden müssen. Angesichts der Tatsache, dass ein kompletter Firmware-Download für ein Gerät über ein einfach zu entfernendes USB-Kabel einige Sekunden dauern kann, ist die Wahrscheinlichkeit relativ groß, dass zumindest einige Anwender diese Prozedur als negativ empfinden. Ideal wäre es, wenn all dies ohne Betätigen einer Taste möglich wäre. Im vorliegenden Artikel geht es um eine einfache Methode zur Implementierung eines Systems, das einerseits die Erkennung zerstörter Firmware und die Aufrechterhaltung des Betriebs ermöglicht und das sich andererseits harmonisch in den Debug und Entwicklungsablauf einfügt.

Individuelle Aufruf-Funktion

Im Unterschied zu früheren BSLs, die stets durch eine bestimmte Zustandswechsel-Sequenz an einem Pin aufgerufen wurden, bieten die BSLs der Serie MSP430 5/6xx eine individuelle Aufruf-Funktion. Diese wird bei jedem Einschalten eines Geräts aufgerufen und überprüft, ob der BSL oder die Anwender-Applikation gestartet werden muss. Bei UART-basierten BSLs wird ein Pin auf eine bestimmte Zustandswechsel-Abfolge hin überwacht. Bei USB-basierten BSLs dagegen wird nach den zuvor erwähnten Kriterien geprüft. Da sich diese Funktion im Flash-Speicher befinden, kann die standardmäßig installierte Aufruf-Funktion entfernt und durch eine eigene Version ersetzt werden. Für diesen Artikel wird die Aufruf-Funktion durch etwas sehr Einfaches ersetzt: die gesamte Geräte-Firmware wird per CRC (Cyclic Redundancy Check) geprüft und mit einem CRC-Resultat verglichen, das sich ganz am Beginn des Anwender-Codes befindet. Da die Bausteine der Serie 5xx über ein eingebautes CRC-Modul verfügen, ist der Code zum Prüfen des gesamten Flash-Inhalts recht einfach:
mov.w #WDTPW+WDTHOLD,&WDTCTL
; Stop WDT

mov.w #0x1D0F, &CRCINIRES

mov.w #START_ADDR, R10
CRC_Loop mova @R10, R11

mov.w R11, &CRCDIRB

incdx.a R10

cmpa #END_ADDR, R10

JL CRC_Loop

CMP.W &(START_ADDR-2),

CRCINIRES

JEQ JUST_RETA

mov.b #0x01, &P1OUT

mov.b #0x01, &P1DIR

REQUEST_BSLBIS.W
#BSL_REQ_APP_CALL, RET_low

JUST_RETA bic.w #PSEIEN,
&USBPHYCTL

mov.b #0x00, &USBKEY

mov.w #WDTPW,&WDTCTL ;

Start WDT

RETA

Dieser Code schaltet zunächst den Watchdog-Timer ab, um ein Auto-Timeout während der Schleife zu unterbinden, initialisiert dann die CRC-Funktion und lädt alle Adressen in das CRC-Modul – von der anwenderdefinierten Startadresse bis zur Endadresse. Stimmt das errechnete CRC-Ergebnis mit dem CRC-Resultat überein, das im Flash-Speicher unmittelbar vor dem Anwendercode abgelegt ist, so ist die Firmware intakt und kann somit gestartet werden. Wird keine Übereinstimmung registriert, wird die Firmware als defekt angenommen und der BSL wird gestartet. Dieser wiederum wartet auf Befehle zum erneuten Start der Firmware-Programmierung. Da auch der BSL selbst individuell ausgestaltet werden kann, könnte der Anwender über die Benutzeroberfläche des jeweiligen Geräts darüber informiert werden, dass ein Firmware-Update erforderlich ist. Vorteilhaft an dieser Methode ist, dass jede Verfälschung der Firmware – nicht nur während eines Upgrades – einen Aufruf des BSL auslöst.

AutomatischeCRC-Generierung

Das Prüfen auf eine verfälschte Firmware mag für Endanwender und für finale Firmware-Versionen attraktiv sein, für Entwickler während des Debugging-Zyklus kann sie sich dagegen als Albtraum erweisen. Jede erneute Compilierung hat einen anderen Firmware-CRC zur Folge und bewirkt, dass anstelle der entwickelten Firmware nun der BSL gestartet wird. Es ist deshalb notwendig, dass die CRC-Generierung automatisch erfolgt und die Entwicklung somit nicht erschwert. Außerdem muss sichergestellt sein, dass die finale Firmware das korrekte CRC-Ergebnis beinhaltet. Es ist ein günstiger Umstand, dass die integrierte Entwicklungsumgebung (Integrat-ed Development Environment – IDE) IAR die Fähigkeit besitzt, automatisch das CRC-Resultat für eine in Arbeit befindliche Firmware zu generieren. Allerdings sind einige besondere Kniffe notwendig, damit diese Funktion mit dem eingebauten CRC-Modul des MSP430 die gesamte Geräte-Firmware erfasst, wie sie auch von der vorgeschlagenen BSL-Firmware überprüft wird. Im Einzelnen sind dazu drei wichtige Änderungen erforderlich. Als erstes muss der gesamte nicht genutzte Speicher als leer (0xFFFF) angenommen werden. Normalerweise laden die IDE-GUI-Optionen nur Werte in nicht genutzten Codespeicher. Um die IDE also zu zwingen, alle Bereiche (beispielsweise auch etwaige Interrupt-Vektoren) zu befüllen, kann die folgende Befehlszeile im Linker genutzt werden. Dabei sind die passenden Adressen für das jeweils verwendete Gerät einzusetzen:

-HAA -h0x4400-0x243FF

Als zweites muss die IDE angewiesen werden, einen CRC-16 über den gesamten Speicherbereich des Geräts zu generieren, wobei die Initialisierung der CRC-Funktion auf die gleiche Weise zu erfolgen hat wie bei der BSL-Aufruffunktion (CRC-CCITT-BR mit 0xFFFF als Startwert). Dies lässt sich erreichen, indem man die folgende Zeile in die Befehlszeilen-Optionen des Projekt-Linkers einfügt:

-J2,crc=1021,,,,1,ffff,0x4402-0x243FF

Schließlich muss der Linker angewiesen werden, den generierten CRC-Code an einer definierten Adresse abzulegen. Hierfür kommt grundsätzlich jede Adresse in Frage, solange sie für BSL und Firmware-Projekt identisch ist. Die Verwendung einer Adresse ganz am Beginn des Anwender-Flash-Bereichs ist allerdings einfacher und erleichtert auch die CRC-Generierung, die in diesem Fall in einem Durchgang erfolgen kann. Hierfür muss in der standardmäßigen Linker-Befehlsdatei nur eine kleine Modifikation vorgenommen werden:

-Z(CONST)CHECKSUM,DATA16_C,DATA16_ID,DIFUNCT=4400-FF7F

Indem man die Variable Checksum ganz am Beginn der Const-Werte platziert, erhält sie automatisch einen Platz ganz am Anfang des gesamten anwendergenerierten Codes. Mit diesen drei Änderungen erreicht man, dass jedes kompilierte Projekt automatisch zur individuellen BSL-Startsequenz passt. Der Entwicklungs und Release-Zyklus wird auf diese Weise gravierend vereinfacht. Es soll nicht verschwiegen werden, dass eine solche Methode nicht frei von bestimmten Nachteilen ist. So hat das Prüfen des gesamten Flash-Bereichs bei jedem Einschalten zur Folge, dass sich die Hochlaufzeit verlängert. Hiergegen kann auf zweierlei Weise Abhilfe geschaffen werden: Erstens kann der Start-Code die DMA-Funktion nutzen, um die Werte zügig in das CRC-Modul zu laden. Dies beschleunigt die Prüfung, erhöht jedoch auch den Codeumfang, was nicht unumschränkt möglich ist, da für den BSL-Code nur 2KByte zur Verfügung stehen. Zweitens könnte die Intelligenz auf der Host-Seite angeordnet werden: nach einem Firmware-Update würde eine PC-residente Host-Applikation die CRC-Prüfung der Firmware vornehmen. Bei Übereinstimmung der CRC-Ergebnisse würde diese Applikation einen bestimmten Schlüssel in eine bekannte, reservierte Adresse schreiben. Der BSL müsste dann beim Start nur diese eine Adresse überprüfen. Findet er dort den Schlüssel, kann er davon ausgehen, dass die Programmierung wie vorgesehen abgelaufen ist. Fehlt der Schlüssel dagegen, muss er davon ausgehen, dass die Programmierung des Geräts auf irgendeine Weise unterbrochen wurde. In diesem Fall muss der BSL gestartet werden. Diese zweite Methode verkürzt die Hochlaufzeit des jeweiligen Geräts entscheidend. Sie schützt auch tatsächlich vor Verfälschungen der Firmware im Zuge von Field-Upgrades. Wenn die Firmware dagegen durch eine andere Ursache beeinträchtigt wird, erfolgt kein BSL-Aufruf. Die Vor und Nachteile beider Methoden müssen für jede Anwendung gegeneinander abgewogen werden.