martedì , 18 Giugno 2019
iten
Home » Elettronica » Configurare una toolchain GCC/Eclipse per STM32Nucleo - Parte II

Configurare una toolchain GCC/Eclipse per STM32Nucleo - Parte II

Nella prima parte di questa serie siamo riusciti a mettere su una tool-chain perfettamente funzionante, basata sull'IDE Eclipse, sulla cross-toolchain di GCC per piattaforme ARM e sui relativi plug-in per integrare il tutto. Abbiamo capito come creare un progetto di esempio e come personalizzarlo per la specifica board Nucleo in nostro possesso. Infine, abbiamo generato il binario del progetto e caricato sul microcontrollore target della nostra board, adoperando ST Link Utility.

Quanto fatto finora potrebbe essere più che sufficiente per sviluppare codice per la piattaforma STM32. Usando la seriale virtuale su USB disponibile con la board Nucleo, potremmo stampare messaggi durante il debugging. Insomma, abbiamo messo su un ambiente equivalente all'IDE di Arduino UNO. Tuttavia, con un po' di ulteriore lavoro successivo, possiamo configurare GDB per eseguire il debugging step-by-step sul micro target, posizionare breakpoint, accedere alla memoria e ai registri del micro. Insomma, fare del vero debugging.

Per fare ciò dovremo configurare GDB in modo da farlo funzionare in modalità client/server e farlo connettere ad un "server" che ingloba tutta la logica di connessione hardware al programmatore ST-Link di bordo sulle Nucleo.

Installare OpenOCD

OpenOCD è un progetto molto ambizioso realizzato da Dominic Rath che ha come scopo la creazione di una sorta di On-Chip-Debugger universale, in grado di interagire con molti MCU presenti sul mercato. Sicuramente, ha un driver interno capace di interagire con il protocollo ST-Link di ST, e quindi può gestire la nostra board Nucleo. OpenOCD è distribuito solo in sorgenti, ma sul sito di Freddie Chopin sono disponibili le versioni precompilate per Windows.

Prima di passare all'installazione di OpenOCD, voglio spendere due parole su come funziona OpenOCD, e in particolar modo di come funziona il debugging di chip STM32 con questo tool e con gdb. Una conoscenza anche sommaria del processo di debugging aiuta sensibilmente a capire come impostare l'ambiente di debug e poi come personalizzarselo a piacimento.

Architettura OpenOCD su ST-Link
Architettura OpenOCD su ST-Link

 

Tipicamente per programmare la flash di un microcontrollore (ed eventualmente eseguire il debugging) abbiamo bisogno di un programmatore esterno. Ogni casa ne produce almeno di un tipo. Vengono chiamati dongle, external programmer, on-chip programmer, ecc. Nel caso dell'ST Microelectronics esiste un apposito programmatore denominato ST-Link. La Nucleo, così come accade per Arduino1, ha già questo programmatore a bordo (e addirittura è "staccabile" e può essere usato stand-alone), quindi non è necessario adoperare strumenti esterni. OpenOCD ha all'interno i driver (sia per la parte USB sia per la parte di protocollo ST-Link) per interfacciarsi con il programmatore. Per farlo funzionare correttamente OpenOCD va istruito tramite dei comandi, contenuti nei file di configurazione. Questi comandi dicono per l'appunto ad OpenOCD quale porta usare, il protocollo, ecc. Una volta che OpenOCD va in esecuzione, e stabilisce la connessione con il programmatore ST-Link della nostra Nucleo, è pronto per interagire con GDB tramite la porta TCP 3333 (si può cambiare, volendo, questa porta) e tramite una connessione telnet opzionale sulla porta 4444. Con queste connessioni si può comandare OpenOCD per fargli caricare il firmware, resettare il micro, proteggerlo da lettura, ecc, ecc. Tutto questo lavoro può essere fatto da Eclipse (e dai plug-in che abbiamo installato), e con questo articolo vedremo come si fa.

Passiamo all'installazione.

Scarichiamo l'ultima versione di OpenOCD (io ho testato con successo la 0.8 - la 0.7 ha troppi problemi, evitatela) da qui. Il file è un archivio compresso con 7-zip, che potete liberamente scaricare dal sito ufficiale. Estraete il contenuto dell'archivio all'interno della directory C:\STM32Toolchain e rinominate la directory da openocd-0.8.0 a semplicemente openocd. Entrate all'interno della directory C:\STM32Toolchain\openocd\bin e rinominate il file openocd-0.8.0.exe semplicemente in openocd.exe.

Questa operazione non è strettamente necessaria. Tuttavia, facendo in questo modo quando sarà rilasciata una nuova versione di OpenOCD non ci sarà alcun bisogno di effettuare modifiche alle configurazioni di Eclipse che ci apprestiamo a fare, ma basterà semplicemente sostituire il contenuto della directory.

1 In realtà, Arduino non ha un programmatore di bordo separato come la Nucleo, ma nel chip principale viene precaricato un pezzo di firmware, denominato bootloader, che si occupa del caricamento del firmware sul chip accettando dei comandi specifici dalla seriale.

Configurare Eclipse

Il passo successivo consiste nel configurare opportunamente Eclipse per lavorare con OpenOCD e GDB. In realtà esistono due metodi di lavoro, in teoria entrambi equivalenti:

  • Metodo 1: configurare Eclipse per far si che ad ogni sessione di debug lanci da prima OpenOCD e poi GDB.
  • Metodo 2: configurare OpenOCD come tool esterno che viene eseguito una sola volta, e poi configurare GDB in modo che si connetta sulla porta 3333 e scambi comandi con OpenOCD.

I plug-in di Eclipse che abbiamo installato nella prima parte permettono di fare tutte e due le cose. Tuttavia, io ho riscontrato problemi con il primo metodo. Purtroppo capita che spesso OpenOCD non riesce a collegarsi con il programmatore ST-Link e l'unico modo per farlo funzionare correttamente è rimuovere la scheda Nucleo e poi ricollegarla. Ho letto che sarebbe un problema dei driver di ST, tuttavia mi chiedo perché poi il software di ST questo problema non l'ha. Probabilmente è un problema di interfacciamento di OpenOCD con i driver di ST. Quindi, conviene lanciare una e una sola volta OpenOCD.

Vediamo come procedere. Assumo che avete attualmente aperto il progetto test1 realizzato nella prima parte.

Clicchiamo sull'icona del menu di configurazione degli External tool, e poi su "External Tool Configurations....", come mostrato in figura

Schermata 2014-12-25 alle 10.13.41

Cliccare sull'icona "New launch configuration" come mostrato in figura

2014-12-25 10_22_40-External Tools Configurations

Ci apparirà la finestra di configurazione. I campi vanno riempiti come mostrato nell'immagine sotto.

2014-12-25 10_39_45-External Tools Configurations

Vediamo il significato di questi campi nel dettaglio.

Location: è il path assoluto dove abbiamo installato OpenOCD, nel nostro caso C:\STM32Toolchain\openocd\bin\openocd.exe.
Working Directory: è la directory di lavoro (il cwd UNIX, per capirci) del processo di OpenOCD una volta eseguito. Serve per poter specificare altri percorsi (quelli degli argomenti) in maniera relativa alla directory di lavoro.
Arguments: sono gli argomenti alla riga di comando da passare a OpenOCD. Nel nostro caso dobbiamo passare lo script di configurazione per la nostra board nucleo (attenzione, nel mio caso si tratta della STM32Nucleo-F401RE; in caso di diversa board verificate nella directory C:\STM32Toolchain\openocd\scripts\board qual è il file specifico per la vostra Nucleo).

Che cosa contiene esattamente il file st_nucleo_f401re.cfg? Si tratta di uno script di configurazione (serie di comandi per OpenOCD). Nello specifico il contenuto è il seguente:

Il primo comando source indica ad OpenOCD di caricare il file di configurazione per l'interfaccia ST-Link versione 2.1 (il programmatore della Nucleo ha un firmware diverso rispetto al programmatore ST-Link in versione 2). Questo file contiene le istruzioni per identificare l'interfaccia USB del programmatore. L'altro comando source indica ad OpenOCD di aprire il file di configurazione che descrive il microcontrollore STM32F4 di bordo sulla nostra scheda.

Clicchiamo su "Apply" e poi su "Run". Di li a poco nella console di Eclipse appariranno una serie di messaggi

e il LED LD1 (vicino al connettore USB) comincerà a lampeggiare in maniera alternata verde/rosso. OpenOCD ha correttamente stabilito la connessione con il programmatore della nostra Nucleo.

Adesso non ci resta che configurare Eclipse per far eseguire GDB. Procediamo nel modo seguente.

Clicchiamo sul menu di configurazione del Debug e poi selezioniamo "Debug Configurations...." come mostrato in figura:

2014-12-25 10_55_36-Debug - test1_src_main.c - Eclipse

Nella finestra successiva selezioniamo prima la voce "GDB Hardware Debug" e poi clicchiamo sull'icona "New launch configuration"

2014-12-25 10_55_06-Debug Configurations

Nella finestra successiva, ci appariranno una serie di tab di configurazione (Main, Debugger, Startup, Source, Common). Nel tab "Main" selezioniamo la voce "Enable auto build".

2014-12-25 10_58_25-Debug Configurations

Nel tab "Debugger" configuriamo i campi come mostrato nella figura sotto:

2014-12-25 10_53_39-Debug Configurations

Vediamo il dettaglio dei singoli parametri di configurazione.

GDB Command: è il percorso dove si trova GDB. Nel nostro caso è C:\STM32Toolchain\gnu-arm\4.8-2014q3\bin\arm-none-eabi-gdb.exe.
JTAG Device: è il tipo di programmatore che stiamo adoperando. Nel nostro caso va selezionato "GNU ARM OpenOCD".
Host name e Port number: vanno settati rispettivamente a localhost e 3333.

Spostiamoci adesso sul tab "Startup" che va configurato come in figura sotto:

2014-12-25 10_54_02-Debug Configurations

Clicchiamo su "Apply" e poi su "Debug". Dopo qualche istante, il nostro programma di esempio verrà caricato sul micro target, e l'IDE si arresterà all'inizio della funzione main(). Abbiamo correttamente configurato il debug della Nucleo con Eclipse.

Non entrerò nei dettagli dell'utilizzo dell'IDE e degli strumenti di debugging, in quanto assumo una certa familiarità con questi strumenti. Nella prossima parte ci occuperemo di altri due aspetti connessi con il debugging: la stampa di messaggi dalla board sulla console dell'IDE (via il semihosting ARM) e l'accesso ai registri interni del microcontrollore.

 

Questo articolo fa parte di una serie di tre post. La prima parte è disponibile qui, la terza qui.

 


Check Also

Come utilizzare la seriale di una scheda STM32 Nucleo

Come vi ho detto nei precedenti tutorial su questa nuova scheda di sviluppo di ST, …

One comment

  1. M, That's a great question. I'm not atulalcy sure of how to prevent eclipse from reporting these errors. Eclipse thinks they're errors because it looks for dependencies that it can't find. Many of these dependencies are present in the makefile however. I'm sure that there's a way to turn these errors OFF. I will look for it and report back. But I find that it does not impede the development process in anyway. If you do find the correct setting to disable these eclipse built in errors I'd appreciate it if you could let me know.Also there is a plugin called the . Once installed it can manage all that makefile stuff for you in the GUI. Please go ahead and check it out. I was able to find a on its use with the STM32F4Discovery board. The settings would be a little different (flags primarily) for the cortex-m0, but its pretty comprehensive. Also you can find all the cortex-m0 flags defined in the makefile.It might not be aesthetically pleasing to the eye but I prefer makefiles ..I guess I'm old school

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.