I laboratori per Kirin 3 della Freescale

Freescale offre molta documentazione per il suo Kirin3, l’MCF52259. Credo che la maggior parte delle persone inizieranno a valutare i laboratori senza leggere i documenti. Io sono uno di questi che odiano la lettura dei documenti.

Se desideri maggiori informazioni su questo prodotto Freescale, invia una richiesta ad Arrow utilizzando il seguente modulo.

Quando ho ricevuto il demo kit Kirin3 da Freescale, non potevo aspettare più e ho iniziato a testare il laboratorio di default fornito con il kit, il progetto web HVAC. Il progetto è perfetto, come descritto in un altro blog ( Web HVAC per KIRIN3 da Freescale). Presenta un server HTTP con host USB/driver MSD nonché lo stile web 2.0 (AJAX). Il secondo giorno, ho provato gli altri laboratori.

Durante la passeggiata attraverso il processo, ho incontrato alcune difficoltà, che voglio condividere con voi.
Ecco l'elenco del laboratorio:

    Lab 1 Controller HVAC, Freescale MQX RTOS per MCF52259
    Lab 2 funzionalità USB, Freescale MQX USB e MFS
    Lab 3 Operazioni FTP e Telnet, Freescale MQX RTCS
    Lab 4 Sistema HVAC web-based, progetto di default
    Lab 5 Trovare un errore utilizzando il Task Aware Debug (TAD) in CodeWarrior
    Lab 6 Ponte Ethernet a Serial

Secondo il manuale di avvio rapido, la procedura ordinaria per ogni laboratorio è:

    Aprire il file di progetto (*. MCP), premere il pulsante Make per creare il progetto di destinazione.
    Utilizzare Tools | Flash Programmer per invocare il programmatore flash, dato che i progetti per la maggior parte sono eseguiti nella memoria flash interna.
    Deselezionare la casella di controllo Use Custom Settings, e caricare le impostazioni da MCF52259_INTFLASH.xml, in cui si definiscono le proprietà della memoria flash interna all’MCF52259.
    Cancellare e controllare se la memoria flash è vuota.
    Programmare e verificare il codice nella memoria flash.
    Avviare il debug o il comando Run nel debugger.

Quando ho cercato di riprodurre il Lab 3, mi sono imbattuto in un problema di cancellazione, che si è per sempre ripetuto, così ho dovuto annullare l'operazione di cancellazione non appena ho capito che era andata male. Ho provato a premere il pulsante di reset, a chiudere ed invocare il CW IDE di nuovo. Infine, ho potuto cancellare il programma e il codice. Ma CW riportava sempre i seguenti avvisi quando si tentava di eseguire il codice.

Exception vector name: Bus Error PC where the exception happened: 0x00000418
Non ho idea su cosa sia questo avviso. Dopo aver verificato nel forum Freescale, ho trovato una discussione su di esso. Può essere causato da un codice inserito nel posto sbagliato a causa di link script o altri motivi. Forse non ho cancellato la memoria flash completamente e il codice non viene eseguito come voglio. Poi ho provato a cancellare il codice diverse volte. Ricevo sempre questo messaggio di avviso. L'altro giorno, avvio CW di nuovo, pulito e costruisco di nuovo il progetto, poi posso cancellare e programmare il codice correttamente. Quindi sapevo che c‘era qualcosa di sbagliato nella procedura di programmazione, dal momento che il codice non è mai stata toccata alcuna linea.
Non avuto mai esperienza su CW+DBM+ColdFire prima. Ma credo che la catena di strumenti dovrebbe essere simile ad altre piattaforme popolari, come Keil+JTAG+ARM. Nella maggior parte dei casi, sono le stesse cose con una terminologia diversa. Così ho trascorso un po’ di tempo a leggere i documenti ed a cercare il forum.

Nel ColdFire di Freescale, Metrowerks CodeWarrior è l'IDE preferito, che include il compilatore, l’assemblatore, il linker ed il debugger front-end. CW può supportare di molti simulatori di software, emulatore di hardware o debug accessibili, compreso OSBDM per ColdFire. OSBDM è stato già montato nel demokit utilizzando fili PCB, invece della normale spina e presa. In teoria, dopo l'accensione sul reset, anche il flash è stato programmato un programma valido, non è possibile eseguire immediatamente, poiché OSBDM ha fermato il codice dall’esecuzione. Tuttavia durante la mia passeggiata, per qualche ragione, forse per colpa mia per un utilizzo improprio dovuto a nessuna lettura di alcun documento, il precedente progetto non può essere arrestato o ricollegato con la OSBDM e CW. Così è ancora in esecuzione, confondendo OSBDM e CW. Come risultato, le seguenti operazioni per cancellare, il controllo del bianco, la programmazione e la verifica sono del tutto fuoricontrollo.

Tutte le operazioni flash sono effettuate da utility in esecuzione su ColdFire. Si possono trovare le seguenti dichiarazioni contenute nei file di log:

    Per l’algoritmo: CFM_MCFCOMMON.elf
    Per le utility: FlashUtility.elf

Quando si richiede a CW di cancellare il chip, programma il codice, scaricherà un pezzo nella RAM per l'esecuzione dell’operazione richiesta. Mi chiedo ancora perché CW possibile scaricarlo nella RAM di ColdFire mentre gli altri progetti sono in esecuzione. Comunque, questo caos è causato dalla mia procedura impropria. Quindi è una buona pratica fermare l'esecuzione del progetto prima di qualsiasi operazione sulla memoria flash. Si può fermare il progetto con diverse procedure in esecuzione e in modalità di debug.

Debug ed Esecuzione
Quando si preme il pulsante di debug in CW, una finestra di debug visualizzerà lo stack, il sorgente e le variabili. Si può andare di passo in passo, un passo avanti, e interrompere ed eliminare la sessione di debug. Quando si chiude il debug dalla finestra di chiusura, CW chiede anche di eliminare o riprendere la sessione di debug. Normalmente, un neofita di CW non commettere errori. Se si preme il pulsante Run in CW, allora nessuna finestra di debug verrà visualizzato, di conseguenza, nessuna richiesta di ricordarvi di eliminare/ interrompere il codice in esecuzione. Quando si chiude ed si esegue di nuovo CW, il codice viene ancora eseguito. Così è più facile ricordarti di interrompere il codice in esecuzione. CW utilizza la terminologia Break, piuttosto che il comando Stop comunemente utilizzato negli altri IDE. Break sta per interrompere manualmente il microcontrollore. Il comando Kill interromperà il codice e chiuderà la finestra di debug e di sessione.

Come fermare il codice in esecuzione
Nel caso in cui si esegue il codice e si chiude CW nella sessione precedente, si farebbe meglio ad eliminare l’esecuzione del codice in ogni caso.

È possibile eseguire nuovamente CW, quindi utilizzando Debug | Attach to process (che mostra la finestra della sorgente) o Debug | Connect (che mostra solo la finestra di interruzione) si ordina di dire a OSBDM/CW di collegare il codice in esecuzione e mostrare una finestra di debug. Così si può eliminare dalla finestra di debug. Ho avuto alcuni dubbi sul fatto se la memoria flash interna possa sopportare la riprogrammazione frequentemente durante lo sviluppo. Finalmente ho tratto una conclusione, devo dubitare di me stesso prima di qualsiasi altra cosa. Ecco altri problemi comuni.

Problemi del Debugger
Sto ancora leggendo il manuale del debugger da Freescale per comprendere l'intera catena di strumenti che lavorano su JM60/OSBDM e CW. Ho trovato che JM60/OSBDM è per MCF52259DEMOKIT, la scheda di valutazione per l’MCF52259 che utilizza PEmicro USB sulla scheda. Ciò significa che anche i progetti debbano modificare le proprie impostazioni per le connessioni debugger in CW, altrimenti CW non riesce a connettersi alla struttura BDM sul chip.

RAM e Flash
Alcuni progetti offrono due destinazioni di costruizione, la RAM e la Flash. In un progetto di costruzione in RAM, si può solo costruire il progetto e avviare la sessione di debug immediatamente, senza avviare la programmazione come nella costruzione flash. Se si tenta di costruire un programma RAM su memoria flash, si riceverà un avviso di errore.

Debug e Release
Si possono anche trovare debug e build di rilascio. In GCC, debug è l'acronimo di un pezzo che include informazioni di debug enormi (simboli, ecc), e la build di rilascio rimuove le informazioni di debug con dimensioni molto più piccole.

Freescale ha significati diversi per il debug e la build di rilascio. Secondo il manuale del debugger per CW, debug è una ottimizzazione bassa (livello 1) che rende più facile eseguire il debug, la build di rilascio è ottimizzata altamente (livello 4) per renderlo più veloce. Entrambe non hanno informazioni di debug nel file.

Problemi di rete
Nei laboratori di rete, ho impostato manualmente 169.254.3.30 sul mio PC. Tuttavia, non riesco a fare il ping sul server Web HVAC dal PC e in nessun altro modo. Sono abbastanza confuso perché ho installato con successo il programma Lab 4 quando ho visto il kit. Ho due connessioni Ethernet, un link al demokit, gli altri collegamenti WiFi al mio router wireless per tenermi in linea. Quando ho disabilitato la connessione WiFi, ho anche ottenuto la comunicazione Ethernet per il demokit.

C'è anche un altro problema, senza alcuna soluzione. Nel Lab 4, quando si utilizza Microsoft FTP per listare e scaricare il file di log dal demokit, l'operazione va in timeout. Tuttavia quando uso FireFTP in Firefox, funziona bene. Ho scaricato l’intera cartella USB nelle mie cartelle locali, e poi ho caricato un file di immagine grande sul demokit.

La velocità di download è di 3KBps e la velocità di upload è di 6KBps. Anche se nel documento, l’ftp di Windows XP è il client FTP preferito, non funziona per me. Forse ho escluso l'FTP di Microsoft prima.

RICHIESTA DI CONTATTO
Se desideri maggiori informazioni su questo prodotto Freescale, invia una richiesta ad Arrow utilizzando il seguente modulo.

Scarica subito una copia gratis

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend