Bootloader per dsPIC30F/33F e PIC24F/24H

Il bootloader per i dispositivi della famiglia dsPIC30F/33F e PIC24H/24F è utilizzato per caricare ed avviare l’applicazione target sul proprio dispositivo. Nell’articolo saranno descritti i concetti base e gli step fondamentali per utilizzarlo.

Il bootloader è costituito da due applicazioni: l’applicazione che deve “girare” all’interno del dispositivo (dsPIC30F/33F o PIC24H/24F) e che deve essere precaricata prima di eseguire qualsiasi altra operazione, e l’applicazione che deve “girare” sul PC host che si occupa di trasferire il file HEX generato con MPLAB o altro ambiente di sviluppo. Il bootloader esegue il parsing del file HEX e lo copia nelle locazioni di memoria appropriate (memoria programma e/o EEPROM se presente) del dispositivo di destinazione. Il tutto è eseguito tramite un canale di comunicazione che generalmente (ma non necessariamente) è una porta seriale (UART); un’alternativa è rappresentata dell’interfaccia CAN. Il bootloader caricato sul targer è un programma memorizzato in un ben precisa locazione di memoria, a partire dall’indirizzo 0x100 (per la famiglia dsPIC30F) oppure da 0x400 (per le altre famiglie). Avviando il dispositivo, il bootloader effettuerà la lettura della locazione di memoria all’indirizzo 0x600 (per la famiglia dsPIC30F) o 0xC00 (per le altre famiglie); il valore memorizzato in tale posizione è un parametro fondamentale detto bootloader delay. Se il bootloader non rileva nessuna attività sulla UART entro il tempo fissato nella suddetta locazione di memoria, esso sospende se stesso e trasferisce l’esecuzione all’applicazione utente, localizzata all’indirizzo di memoria 0x602 (per la famiglia dsPIC30F) e 0xC02 (per le altre famiglie). Diversamente, se è rilevata attività sulla seriale prima del timeout, esso esegue la programmazione della EEPROM (se presente) e della memoria programma con i dati ricevuti dall’applicazione eseguita sul PC host (vedi figura 1).

Figura 1: rappresentazione schematica del processo di bootloader, per il trasferimento di file dal PC host all’applicazione target

L’applicazione che risiede sul PC host effettua il parsing del file HEX generato dall’ambiente di sviluppo utilizzato (MPLAB o altri) ed invia questi dati all’applicazione target, tramite UART. L’applicazione host supporta alcune funzioni addizionali come la lettura della memoria programma e della EEPROM.

Utilizzo della memoria del dispositivo

Sebbene il bootloader sia abbastanza ridotto in termini di memoria occupata, l’architettura del dispositivo pone un vincolo sull’organizzazione all’interno della memoria del bootloader stesso e dell’applicazione utente. Prima che la memoria Flash possa essere programmata, il bootloader deve cancellarla. Questa operazione può essere eseguita sia cancellando l’intera memoria Flash, che cancellando pagine di memoria (equivalenti a 512 istruzioni di tipo long). La figura 2 illustra l’organizzazione della memoria per le famiglie dsPIC33F, PIC24H e PIC24F.

Figura 2: organizzazione della memoria per le famiglie
dsPIC33F, PIC24H e PIC24F.

La tabella dell’interrupt (IVT/AIVT) utilizza uno spazio di memoria fino a 0x1FE. Il bootloader non può essere posizionato immediatamente dopo questo indirizzo poiché la cancellazione della prima pagina di memoria comporterebbe la cancellazione anche del bootloader. Per quanto detto sopra il bootloader deve essere memorizzato a partire dalla seconda pagina, cioè dall’indirizzo 0x400; questo comporta un “buco” di memoria inutilizzata da 0x200 a 03FE. Comunque, tali locazione possono essere utilizzate in qualche modo dall’applicazione utente. Sempre a causa della limitazione delle pagine della Flash, l’applicazione utente non potrà essere posizionata immediatamente dopo il bootloader. Essa deve essere inserita a partire dall’indirizzo 0xC00, cioè dalla pagina successiva. A partire da questo indirizzo (0xC00) deve essere specificato il valore del bootloader delay e quindi del codice utente vero e proprio. Le pagine di memoria Flash sono più piccole per i dispositivi della famiglia dsPIC30F e quindi le locazioni del bootloader e della user application sono differenti, anche se il principio ispiratore non cambia (per maggiori dettagli vedere la figura 3).

Figura 3: organizzazione della memoria per la
dsPIC30F.

Utilizzo delle periferiche del dispositivo

L’applicazione target utilizza la memoria programma dall’indirizzo 0x100 a 0x600 per i dispositivi dsPIC30F e da 0x400 a 0xC00 per i dispositivi dsPIC33F e PIC24/24F. Inoltre, esso utilizza il vettore di reset della IVT (Interrupt Vector Table). Le periferiche sono:

➤ UART (nel caso in cui la trasmissione del codice avvenga tramite interfaccia seriale).

➤ Timer (per la gestione del bootloader delay).

Le massime prestazioni misurate per il bootloader su dsPIC33F si attestano intorno a 8.1kbps.

File utilizzati

Il bootloader è organizzato in due differenti sotto-directory:

➤ Target Side: …\Bootloader\targer;

➤ Host Side: …\Bootloader\host L’applicazione che girerà sul target è fornita da Microchip ed è sviluppata ovviamente utilizzando MPLAB come ambiente di sviluppo:

➤ file di progetto: 16-bit Flash Programmer.mcp, 16-bit Flash Programmer.mcw;

➤ programma principale (esegue tutti i task principali, come inizializzazioni e comunicazione con l’host): main.c;

➤ Support File (contengono le routine della memoria per la scrittura e lettura): memory.s;

➤ Test Application Files (posizionati in.\test directory).

L’applicazione host è, invece, sviluppata utilizzando il linguaggio di programmazione Visual C++ ed è composta dai seguenti file:

➤ file di progetto;

➤ programma principale;

➤ Command line parsing class (utilizzato per effettuare il parsing e validare gli argomenti passati da linea di comando);

➤ Memory class (utilizzato per effettuare

il parsing del file HEX);

➤ file eseguibili.

Compilazione del booloader

Il bootloader può essere compilato in due differenti modalità: Debug, Standalone.

Modalità debug

Se si desidera effettuare il debug del codice del bootloader con ICD2, è necessario selezionare la modalità debug. Per far ciò seguire i passi di seguito riportati:

■ 1-Aprire il file di progetto: 16-bit Flash Programmer.mcp

■ 2-Dal menu Project selezionare il comando Build

■ 3-Collegare la scheda al computer host tramite ICD2.

■ 4-Dal menu Debugger, selezionare Select Tool e poi fare click su ICD2.

■ 5-Dal menu Debugger, selezionare Program e poi fare click su Run.

A questo punto, la progress bar indicherà che l’applicazione è in esecuzione.

Modalità stand-alone

Se non si desidera effettuare il debug del bootloader, è possibile compilarlo e caricarlo in modalità stand-alone. In questo caso vanno seguiti i seguenti passi:

➤ aprire il file di progetto: 16-bit Flash Programmer.mcp;

➤ dal menu Project selezionare il comando Build;

➤ collegare la scheda con il dispositivo al computer host tramite ICD2;

➤ dal menu Programmer, selezionare Select Tool e poi fare click su ICD2;

➤ dal menu Programmer, selezionare Program;

➤ effettuare il reset della scheda.

A questo punto il bootloader leggerà la locazione che contiene il valore del timeout e, poiché la Flash è stata appenda cancellata con la programmazione, il valore sarà pari a 0xFF. L’applicazione host del bootloader può essere ricompilata con il file di progetto 16-Bit Flash Programmer.vcproj; comunque, a meno di modifiche al sorgente, tale operazione non sarà necessaria poiché è già fornito il file eseguibile.

Requisiti per l’applicazione utente

I seguenti requisiti devono essere applicati a qualunque applicazione utente che sarà programmata tramite il bootloader descritto:

➤ l’applicazione utente non deve inserire

codice nell’area riserva al bootloader;

➤ l’applicazione utente deve rientrare all’interno dello spazio di memoria del target device;

➤ deve essere specificato il valore del

delay per l’avvio dell’applicazione.

Per soddisfare questi requisiti, il file di linker (.GLD) corrispondente all’applicazione utente deve essere modificato. In particolare bisogna indicare l’indirizzo iniziale del codice e il valore del bootloader delay.

Modifica al file .GLD per dsPIC30F

Per i dispositivi della famiglia dsPIC30F il file del linker è modificato in modo da porre l’inizio dell’applicazione utente all’indirizzo 0x602 e fornire un valore di timeout per il bootloader. Il listato 1 riporta un esempio di tale file.

program (xr) : ORIGIN = 0x600, LENGTH = ((16K * 2) - 0x600)
__CODE_BASE = 0x600; /* Handles, User Code, Library Code */
/*
** User Code and Library Code
*/
.text __CODE_BASE :
{
SHORT(0x0A); /* Bootloader timeout in sec */
*(.handle);
*(.libc) *(.libm) *(.libdsp);
*(.lib*);
*(.text);
} >program

Listato 1

Modifica al file .GLD per dsPIC33F e PIC24F/24H

Per i chip della famiglia dsPIC33F e PIC24F/24H, la modifica al file .GLD consiste nel posizionare l’applicazione utente all’indirizzo 0xC02 e impostare il timeout. Fare riferimento al listato 2 per ulteriori dettagli.

program (xr) : ORIGIN = 0xC00, LENGTH = 0x29E00
__CODE_BASE = 0xC00; /* Handles, User Code, Library Code */
/*
** User Code and Library Code
*/
.text __CODE_BASE :
{
SHORT(0x0A); /* Bootloader timeout in sec */
*(.handle);
*(.libc) *(.libm) *(.libdsp);
*(.lib*);
*(.text);
} >program

Listato 2

Trasferimento del file

Per il trasferimento del file è necessario utilizzare l’applicazione scritta in VisualC++. Essa può essere eseguita da linea di comando utilizzando la seguente sintassi riportata nella tabella 1.