Mais pourquoi un tel étalage de Pi Pico, @f-leb ? Tu prépares une expo de Pico ? Une pico party ?
Mais non... À droite, vous avez la Pi Pico cible que l'on veut programmer et déboguer.
La Pi Pico de gauche fait l'interface entre le PC de développement et la Pi Pico cible à droite, et constituera un dispositif communément appelé sonde de débogage.
Notre sonde aura donc trois fonctions :
- Programmer plus facilement la cible depuis le PC de développement. Parce que passer la cible en mode USB pour qu'elle se comporte comme un périphérique de stockage USB (on appuie sur le bouton Bootsel tout en branchant le câble USB, ou en faisant un Reset...), faire glisser le binaire uf2 depuis l'explorateur de fichiers, c'est bien au début, mais la répétition de ces manipulations devient vite pénible pendant la mise au point de vos programmes...
- Déboguer bien sûr, la possibilité de dérouler le programme pas-à-pas ou jusqu'à des points d'arrêt, voir l'état des variables, des registres, de la pile d'appel, etc.
- En bonus, elle pourra servir de pont USB-UART pour échanger facilement des informations série UART entre la cible et le PC de développement.
Je ne développerai que la première fonction dans ce billet, et notre Pico bis sera donc un simple programmateur pour l'instant, ce qui la rend déjà bien utile, mais j'espère bien aborder la partie débogage dans un futur billet...
À noter que la Fondation Raspberry Pi a évidemment senti le filon en proposant sa propre sonde Raspberry Pi Debug Probe officielle qui est beaucoup plus jolie avec son boîtier transparent et ses câbles à connecteurs JST. En quelque sorte, notre deuxième Pi Pico constituera la sonde de débogage du pauvre, mais elle marchera très bien (surtout que la sonde officielle est une Pico déguisée...).
Sur le plan matériel, il faut relier la sonde au port SWD (Serial Wire Debug) de la Pi Pico cible. Pour cela, il faudra souder quelques broches...
Port de débogage SWD avec ses trois broches soudées :
SWCLK, GND, SWDIO
Sur le schéma de câblage ci-dessous, on voit comment la sonde (à gauche) est reliée au port SWD de la Pi Pico cible (à droite). La cible est alimentée en reliant les broches VSYS (3,3V) des deux cartes.
Installation du firmware picobrobe
Il faut ensuite installer le firmware picobrobe dans la sonde. Vous pouvez récupérer les sources en clonant le dépôt Github officiel de la Fondation Raspberry Pi, générer le projet (build) et le téléverser dans la sonde comme n'importe quel autre projet en faisant un glisser-déposer du fichier picoprobe.uf2 :
Code bash : | Sélectionner tout |
1 2 3 4 5 6 7 8 | $ cd ~/pico $ git clone https://github.com/raspberrypi/picoprobe.git $ cd picoprobe $ git submodule update --init $ mkdir build $ cd build $ cmake .. $ make -j4 |
Encore plus rapidement, vous récupérez directement la dernière release du fichier picoprobe.uf2.
Installation du logiciel OpenOCD
OpenOCD (Open On-Chip Debugger) est le logiciel qui parle à l'oreille des microcontrôleurs. Il supporte le protocole SWD pour communiquer directement avec les cœurs de processeurs à base d'ARM comme le RP2040 de la Pi Pico.
Pour installer la version d'openOCD (un fork) qui supporte la Raspberry Pi Pico (avec une distribution Linux Debian/Ubuntu) :
Code bash : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 | $ cd ~/pico-sdk $ sudo apt install automake autoconf build-essential texinfo libtool libftdi-dev libusb-1.0-0- dev $ git clone https://github.com/raspberrypi/openocd.git --branch rp2040 --depth=1 $ cd openocd $ ./bootstrap $ ./configure $ make -j4 $ sudo make install |
Pour tester l'installation :
Code bash : | Sélectionner tout |
1 2 3 4 5 6 | $ openocd --version Open On-Chip Debugger 0.11.0-g8e3c38f (2023-05-08-11:34) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html |
Test du programmateur SWD
Il ne reste plus qu'à tester le fonctionnement de notre nouveau programmateur. Si vous avez suivi le premier billet de la série, vous avez sans doute conservé le projet de démonstration blink qui fait clignoter la LED de la carte. Rendez-vous dans ce cas dans le sous-dossier build du projet qui doit déjà contenir le fichier binaire blink.elf prêt à téléverser.
Il reste à lancer la commande :
Code bash : | Sélectionner tout |
sudo openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "adapter speed 5000" -c "program blink.elf verify reset exit"
Compte-rendu de la commande dans le terminal :
Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 | Open On-Chip Debugger 0.11.0-g8e3c38f (2023-05-08-11:34) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'. Info : Hardware thread awareness created Info : Hardware thread awareness created Info : RP2040 Flash Bank Command adapter speed: 5000 kHz Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E660443043955E2B Info : CMSIS-DAP: SWD Supported Info : CMSIS-DAP: FW Version = 2.0.0 Info : CMSIS-DAP: Interface Initialised (SWD) Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0 Info : CMSIS-DAP: Interface ready Info : clock speed 5000 kHz Info : SWD DPIDR 0x0bc12477 Info : SWD DLPIDR 0x00000001 Info : SWD DPIDR 0x0bc12477 Info : SWD DLPIDR 0x10000001 Info : rp2040.core0: hardware has 4 breakpoints, 2 watchpoints Info : rp2040.core1: hardware has 4 breakpoints, 2 watchpoints Info : starting gdb server for rp2040.core0 on 3333 Info : Listening on port 3333 for gdb connections target halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00 ** Programming Started ** Info : RP2040 B0 Flash Probe: 2097152 bytes @10000000, in 512 sectors target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 Info : Writing 24576 bytes starting at 0x0 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 ** Programming Finished ** ** Verify Started ** target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 ** Verified OK ** ** Resetting Target ** shutdown command invoked |
Si l'opération échoue avec le message Info: DAP init failed, c'est qu'OpenOCD ne voit pas la cible par l'interface SWD. Il faudra vérifier les câbles, le câblage, l'alimentation des cartes... et ouvrir une discussion sur le forum Raspberry Pi le cas échéant
À suivre...
Sitographie
- Document Getting started whith Raspberry Pi Pico, Appendix A: Using Picoprobe
- Sur Developpez : La Fondation Raspberry Pi lance une sonde de débogage pour le Pi Pico et d'autres cartes basées sur Arm.