Beschreibung

Protokoll

PC-Tool

Download

Konfiguration

Applikation

Konfiguration:

Anpassung der Bootloader-Firmware an das Zielsystem

Bevor der Bootloader in den PIC programmiert werden kann, muss der Quelltext (bootloader.asm) auf die Zielhardware angepasst und assembliert werden. Dazu wird zunächst in der Entwicklungsumgebung der verwendete PIC-Typ eingestellt. Im Quelltext gibt es bereits für verschiedene Controllertypen jeweils einen Abschnitt, der automatisch die entsprechende "<Controllertyp>.INC"-Datei einbindet, sowie einige #define-Anweisungen für Controller-spezifische Einstellungen enthält. Wenn der verwendete Controller hier noch nicht aufgeführt ist, muss ein entsprechender Abschnitt für den neuen Controller eingefügt werden.

Configuration Words des PICs

Adressbereich für den Bootloader-Code: #define BL_LOCATION <addr>

Mit "#define BL_LOCATION 0" wird der Bootloader am Anfang des Flashspeichers abgelegt. Die Applikation wird dann hinter den Bootloader geladen und die Startadresse der Applikation muss entsprechend angepasst werden. Bei dieser Variante ist der Bootloader etwas kürzer und beim Ladevorgang der Applikation wird kein Flash im Bootloader- oder Resetvektor-Bereich umprogrammiert. Selbst ein Fehler im ungünstigsten Moment (z.B. Reset während des Programmiervorgangs) kann nicht dazu führen, daß der Bootloader nicht mehr funktioniert.
Die Startadresse der Applikation wird weiter unten im Quelltext durch "#define APP_START <addr>" festgelegt (Standard: 0x100). Je nach der tatsächlichen Länge des Bootloader-Codes, kann diese Adresse ggf. noch verändert werden, um etwas mehr Speicherplatz für die Applikation zur Verfügung zu stellen. Der APP_START Wert muss immer auf den Anfang eines Flash Erase Blocks fallen!

Um den Bootloader ganz ans Ende des Flashspeichers zu legen, wird ";#define BL_LOCATION" auskommentiert, wodurch die Startadresse dann automatisch anhand von "FLASHSIZE" eingestellt wird. Die Applikation nutzt dann den gleichen, unteren Speicherbereich, in den sie auch ohne Bootloader geladen würde. Der Resetvektor muss allerdings trotzdem auf den Bootloader zeigen! Der Bootloader erlaubt nicht, den Resetvektor zu ändern. Hier gibt es aber einen kurzen, kritischen Moment zwischen Löschen und Neuprogrammierung des ersten Flash-Erase Blocks, bei dem z.B. ein Ausfall der Versorgungsspannung zum Löschen des Resetvektors führen würde. Der Controller könnte dann nur noch mit Hilfe eines Programmiergerätes wieder in Betrieb genommen werden.

Mit "#define BL_LOCATION <addr>" kann auch eine alternative Startadresse für den Bootloader vorgegeben werden (an Flash Erase Block ausrichten!). So kann man einen Speicherbereich über dem Bootloader z.B. mit "High Endurance Flash" als Daten-Flash für die Applikation reservieren.

Die acht Flash-Worte vor dem Bootloader ("Patchcode", Adressen: BL_LOCATION-8 bis BL_LOCATION-1) sind für den umgelagerten Reset-Code der Applikation und Prüfsummen-Informationen reserviert.

Verifikation der Applikation (optional): #define ENABLE_CHECKSUM

Wenn das Symbol "ENABLE_CHECKSUM" definiert ist, bildet der Bootloader über den Applikationscode eine Prüfsumme und startet die Applikation nur, wenn die Summe über den spezifizierten Codebereich, incl. der Prüfsumme selbst, 0 ergibt. So wird verhindert, daß undefinierter oder fehlerhafter Code mit unvorhersagbaren Auswirkungen ausgeführt wird. Ggf. bleibt dann der Bootloader aktiv.

Wird diese Zeile auskommentiert, findet keine Verifikation der Applikation statt und der Bootloader ist um ca. 24 Words kürzer. Auf die Auswertung der Prüfsummen für die Datenpakete beim Upload hat dieser Einstellung aber keinen Einfluss!

Kommunikations Interface:

Eindraht/Halbduplex
"#define COM_PORT <Port>" und "#define COM_PIN <Bit>" definiert den I/O-Port und dessen Bitnummer für die serielle Schnittstelle, mit Halbduplex als Betriebsart.

Zweidraht/Vollduplex
"#define TX_PORT <Port>", "#define TX_PIN <Bit>", "#define RX_PORT <Port>" und "#define RX_PIN <Bit>" definieren den Rx- und Tx-Port für eine Vollduplex-Schnittstelle. COM_PORT und COM_PIN dürfen dann nicht definiert ein!

"#define LOADER_BAUD" spezifiziert die Übertragungsgeschwindigkeit (max.115200 Baud). Das Übertragungsformat ist 8 Datenbits mit einem Start- und einem Stopbit, ohne Parity.

Hardware-UART
Wenn der Controller über ein EUSART-Modul verfügt, kann mit "#define EUSART" dieses anstelle des Software-UARTs verwendet werden, wodurch sich der Programmcode etwas verkürzt.
Wenn der Controller über ein "Peripheral Pin Select"-Modul (PPS) verfügt, werden hier Rx/Tx-Pins und Betriebsart (Voll- oder Halbduplex) wie beim Software-UART definiert. Falls der Controller kein PPS-Modul hat, ist mit dem EUSART nur Vollduplex-Betrieb über zwei getrennte Pins (Tx/Rx) möglich, und die TX_PORT/RX_PORT-Definitionen müssen auf die entsprechenden, durch die Hardware vorgegebenen EUSART-Pins eingestellt werden.
Bei einigen PICs lassen sich die EUSART Pins per APFCON-Register auf alternative Pins legen. Diese Form des Pin-Mappings ist im   Bootloader bisher nicht implementiert, d.h. es sollten bei Verwendung des EUSART Moduls nur die Pins benutzt werden, die nach einem Reset voreingestellt sind. Um das EUSART-Modul mit alternative Pins zu nutzen, muss ggf. zusätzlicher Code für das Setzen des APFCON-Registers eingefügt werden.

Boot-Pin (optional):

Mit "#define BOOT_PORT <Port>" und "#define BOOT_PIN <Bit>" kann ein I/O-Pin definiert werden, über den beim Reset der Start des Bootloaders, statt der Applikation, erzwungen werden kann. Hier kann z.B. ein Jumper oder Taster angeschlossen werden, der beim Einschalten des Gerätes gedrückt wird, um in den Bootloader zu gelangen. Mit "#define NBOOT_PIN <Bit>" anstelle von "#define BOOT_PIN <Bit>" wird der Pin als Low-Aktiv gekennzeichnet.

Ohne Boot-Pin Option startet der Bootloader die Applikation, wenn er nicht innerhalb einer Sekunde nach einem Reset Daten über die serielle Schnittstelle empfängt.

LED-Pin (optional):

Mit "#define LED_PORT <Port>" und "#define LED_PIN <Bit>" bzw. "#define NLED_PIN <Bit>" kann eine am entsprechenden Pin angeschlossene LED durch den Bootloader angesteuert werden, um dessen Aktivität anzuzeigen.

Laden/Update des Bootloaders durch den Bootloader 

Der Bootloader-Code und der Reset-Vektor lassen sich nicht einfach per Bootloader-"Write" Befehl überschreiben, deshalb ist ein besonderer Mechanismus notwendig, um eine Aktualisierung des Bootloaders selbst vorzunehmen, falls der neue Bootloader nicht einfach per Programmiergerät in den PIC geflasht werden kann.
Zunächst muss ein Hex-File mit dem Bootloader in einem anderen Adressbereich erzeugt werden, damit er nicht mit dem aktuell installierten ("alten") Bootloader kollidiert. Dieses Hex-File kann dann über das PICLoader-Tool vom "alten" Bootloader wie eine normale Applikation in den PIC geladen werden, allerdings muss dann noch der Reset-Vektor auf den "neuen" Bootloader umgebogen werden, um aus der normalen Applikation einen richtigen Bootloader zu machen. Diese Aktion wird über eine kleine "Installer"-Applikation durchgeführt, die automatisch zusammen mit dem Bootloader geladen wird. PICLoader erkennt die Installer-Applikation anhand einer Signatur und bildet dafür die Prüfsumme, damit der "neue" Bootloader den Installer als gültige Applikation erkennt und ausführt.

Um den Bootloader in seinem original-Adressbereich upzudaten, müssen zwei Bootloader-Hexfiles für jeweils unterschiedliche Adressbereiche erzeugt werden  und der Updatevorgang mit jeder Datei einmal durchgeführt werden.