Le blog de f-leb

[Actualité] [Raspberry Pi Pico][SDK C/C++] Déboguer la Raspberry Pi Pico avec une sonde dans Visual Studio Code

Noter ce billet

par

f-leb

, 26/05/2023 à 09h00 (6574 Affichages)

Au billet précédent de la série, nous avions déjà mis en œuvre une deuxième Raspberry Pi Pico en tant que programmateur par le port SWD (Serial Wire Debug) de la Pi Pico cible. Il est temps d'exploiter pleinement le potentiel de cette deuxième Pi Pico et d'en faire une véritable sonde de débogage. Et pour gagner en confort, les opérations de débogage seront menées depuis l'EDI opensource Visual Studio Code de Microsoft.

Débogage avec printf(), pour commencer

Parmi les techniques de débogage, vous êtes certainement déjà passés par des remontées d'informations série à coups de printf() (ou de Serial.print() sur Arduino) pour affichage dans un terminal. On a déjà eu recours à printf() dans ce billet, mais les données série doivent maintenant remonter par la sonde. Pour cela, il faut compléter le câblage avec les deux fils gainés bleu et magenta du schéma ci-dessous qui partent des broches UART0 TX et UART0 RX de la Pi Pico cible :

De plus, le fichier CMakeLists.txt doit être modifié pour que la sortie standard passe par le port UART par défaut, et non plus par le port USB, soit :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
pico_enable_stdio_usb(NomDuProjet 0)
pico_enable_stdio_uart(NomDuProjet 1)
La sonde avec le firmware picoprobe se charge alors de faire la passerelle UART-USB avec le PC de développement pour un affichage avec minicom par exemple :
Code bash : Sélectionner tout - Visualiser dans une fenêtre à part
sudo minicom -b 115200 -o -D /dev/ttyACM0
Installation de VSCode

Pour autant, procéder avec des printf() ne résout pas tous les bogues et il faut passer par un outil dédié pour comprendre comment votre code est vraiment interprété alors que vous vous attendiez à un comportement différent. Le programme gdb (The GNU Project Debugger) vous permettra de dérouler votre code jusqu'à des points d'arrêt ou pas-à-pas en sondant le contenu des variables, de la pile d'appels, des registres, de la mémoire, etc. ce qui en fait un outil très puissant.

Pour installer gdb :
Code bash : Sélectionner tout - Visualiser dans une fenêtre à part
$ sudo apt install gdb-multiarch
Pour les détails de l'installation de VSCode et des extensions, reportez-vous au getting started with Raspberry Pi Pico, en particulier au chapitre 7. Using Visual Studio Code.

Cela donne en gros :
Code bash : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
$ sudo apt install code
$ code --install-extension marus25.cortex-debug
$ code --install-extension ms-vscode.cmake-tools
$ code --install-extension ms-vscode.cpptools
Je n'ai pas rencontré de difficultés jusque-là quand j'ouvre un projet comme le blink ci-dessous :

Dans la barre tout en bas, on peut choisir la configuration CMake:[Debug], configuration par défaut pour le débogage ou CMake:[Release] pour distribuer la version finale. On sélectionne le kit GCC xx.y.z arm-none-eabi. Pour générer le projet, il ne reste plus normalement qu'à cliquer sur l'icône Build avec la roue dentée et voir le compte-rendu défiler en sortie.
Le sous-dossier build du projet doit contenir les binaires blink.uf2 qui peut être glissée-déposée dans la Pi Pico vue comme un périphérique USB, et blink.elf qui servira justement pour le débogage par le port SWD.
Pour l'instant, il faut encore lancer OpenOCD en ligne de commande pour programmer la cible (voir le billet précédent), mais on gagne en confort avec un éditeur moderne, la coloration syntaxique, l'autocomplétion, l'intelliSense, etc.

Configuration pour le débogage dans VSCode

Ici, ça se gâte un peu... Il va falloir faire le lien entre VSCode, les extensions et les outils OpenOCD et gdb pour que tout cela puisse être utilisé à partir de l'interface graphique. On a beau dire, la documentation est bien faite, mais... et comme c'est amusant, ça ne se passe pas toujours comme dans la documentation.

Premièrement, depuis votre dossier projet, il vous faut créer un sous-dossier mon_projet/.vscode contenant les deux fichiers de configuration au format json : launch.json et settings.json. La Fondation Raspberry Pi vous propose de récupérer ces deux fichiers sur son dépôt : Sample configuration files for developing with VSCode and the SWD port.
Il faut normalement prendre le fichier launch-xxxxxxxxxx.json le plus proche de votre configuration et le copier en launch.json dans mon_projet/.vscode. On peut recopier tel quel le fichier settings.json dans mon_projet/.vscode. C'est là qu'on peut avoir des surprises, selon votre distribution Linux et sa configuration je suppose... Je vous mets en complément tout en bas de ce billet la configuration qui a fonctionné chez moi (distribution Lubuntu classique).

Deuxièmement, par défaut OpenOCD a besoin des privilèges root (avec sudo) pour s'exécuter, et c'est embêtant dans VSCode. Je vous mets un autre complément tout en bas de ce billet pour pouvoir exécuter OpenOCD sans sudo.

Et si tout est bien configuré...

Quand on appuie sur l’icône du bouton Exécuter et déboguer à gauche (ou par Ctrl+Maj+d), et que l’on clique sur la flèche verte Démarrer le débogage (F5), la session de débogage débute avec une première pause à un point d’arrêt provisoire juste après le main().

La programmation de la cible peut être lancée et la session de débogage peut commencer.
J'espère pouvoir trouver un programme bogué pour décrire une petite session de débogage dans un prochain billet, je devrais avoir l'embarras du choix...

‐------------‐-----‐-------------------------------
Complément 1 : les fichiers de configuration VSCode

Si vous prenez le fichier launch.json proposé, vous risquez d'avoir malgré tout le message Error: CMSIS-DAP command CMD_DAP_SWJ_CLOCK failed parce qu'OpenOCD est exécuté sans l'argument "adapter speed 5000" (fréquence de transmission 5000 Hz). Curieux cet oubli... J'ai trouvé une solution en complétant le fichier launch.json comme ci-dessous. On doit pouvoir aussi modifier le fichier target/rp2040.cfg comme expliqué ici, je n'ai pas testé mais c'est peut-être plus judicieux...
launch.json :
Code json : Sélectionner tout - Visualiser dans une fenêtre à part
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
{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Pico Debug",
            "cwd": "${workspaceRoot}",
            "executable": "${command:cmake.launchTargetPath}",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "openocd",
            "gdbPath": "gdb-multiarch",
            "device": "RP2040",
            "configFiles": [
                "interface/cmsis-dap.cfg",
                "target/rp2040.cfg"
            ],
            "svdFile": "${env:PICO_SDK_PATH}/src/rp2040/hardware_regs/rp2040.svd",
            "runToEntryPoint": "main",
            "postRestartCommands": [
                "break main",
                "continue"
            ],
            "serverArgs": ["-c", "adapter speed 5000"]
        },
        {
            "name": "C/C++: arm-none-eabi-gcc Générer et déboguer le fichier actif",
            "type": "cppdbg",
            "request": "launch",
            "program": "${fileDirname}/${fileBasenameNoExtension}",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${fileDirname}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Activer l'impression en mode Pretty pour gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                },
                {
                    "description": "Définir la version désassemblage sur Intel",
                    "text": "-gdb-set disassembly-flavor intel",
                    "ignoreFailures": true
                }
            ],
            "preLaunchTask": "C/C++: arm-none-eabi-gcc générer le fichier actif",
            "miDebuggerPath": "/usr/bin/gdb"
        }
    ]
}
settings.json
Code json : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
  "cmake.configureOnOpen": false,
  "cmake.statusbar.advanced": {
    "debug" : {
      "visibility": "hidden"
              },
    "launch" : {
      "visibility": "hidden"
               },
    "build" : {
      "visibility": "hidden"
               },
    "buildTarget" : {
      "visibility": "hidden"
               },
     },
}
‐------------‐-----‐-------------------------------
Complément 2 : exécuter OpenOCD sans les privilèges root

Par défaut, OpenOCD ne peut communiquer avec la sonde par le port USB que s'il est exécuté avec les privilèges root (avec sudo).
On vous explique ici les démarches à faire pour enlever ces privilèges.

Avec la commande groups, vous verrez que l'utilisateur courant n'appartient pas au groupe plugdev par défaut.

Pour ajouter l'utilisateur courant au groupe plugdev, tapez alors :
Code bash : Sélectionner tout - Visualiser dans une fenêtre à part
sudo useradd -G plugdev ($whoami)
Une fois la sonde connectée au port USB, relever les identifiants du vendeur et du produit avec la commande lsusb -v :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Bus 001 Device 003: ID 2e8a:000c Raspberry Pi Picoprobe (CMSIS-DAP)
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.10
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x2e8a 
  idProduct          0x000c 
  bcdDevice            1.01
  iManufacturer           1 Raspberry Pi
  iProduct                2 Picoprobe (CMSIS-DAP)
  iSerial                 3 E660443043955E2B
  bNumConfigurations      1
  Configuration Descriptor: ....
...
Ici : idVendor = 2e8a, et idProduct = 000c (et pour la sonde officielle debug Probe, il faut sans doute prendre idProduct = 0004).

Rendez-vous ensuite dans le dossier /etc/udev/rules.d :
Code bash : Sélectionner tout - Visualiser dans une fenêtre à part
cd /etc/udev/rules.d
Créez et éditez un nouveau fichier 60-openocd.rules, par exemple avec nano :
Code bash : Sélectionner tout - Visualiser dans une fenêtre à part
sudo nano 60-openocd.rules
Créez et sauvegardez le fichier 60-openocd.rules avec le contenu suivant comprenant les identifiants trouvés précédemment :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
# Raspberry Pi Picoprobe
ATTRS{idVendor}=="2e8a", ATTRS{idProduct}=="000c", MODE="660", GROUP="plugdev", TAG+="uaccess"
Si on en a besoin, OpenOCD propose un fichier des règles udev très complet prenant en compte davantage de matériels : 60-openocd.rules

Rechargez les nouvelles règles udev avec la commande :
Code bash : Sélectionner tout - Visualiser dans une fenêtre à part
sudo udevadm control --reload
Ainsi, tout membre du groupe plugdev devrait pouvoir exécuter OpenOCD sans utiliser sudo.