Introduction

 

Le débogage d’un programme sur STM32CubeIDE sert à identifier et à corriger les erreurs dans le code source d’un microcontrôleur STM32.

Voici les principales utilisations du débogage :

1. Identifier les Bugs : Le débogage permet de trouver et de comprendre les erreurs ou les comportements inattendus dans le programme.
2. Suivi du Flux d’Exécution : Il permet de suivre l’exécution du code ligne par ligne, ce qui aide à comprendre comment le programme fonctionne en temps réel.
3. Vérification des Valeurs des Variables : Les développeurs peuvent surveiller et modifier les valeurs des variables pour voir comment elles changent au cours de l’exécution.
4. Points d’Arrêt (Breakpoints) : Ils permettent de suspendre l’exécution du programme à des endroits spécifiques pour analyser l’état du système.
5. Analyse des Registres : Pour les microcontrôleurs, il est possible de vérifier et de modifier les registres pour s’assurer qu’ils fonctionnent correctement.
6. Gestion des Interruptions : Permet de tester et de vérifier la gestion des interruptions par le microcontrôleur.

Le débogage est essentiel pour assurer que le programme fonctionne correctement et efficacement sur le microcontrôleur STM32.

Serial Wire debug

Pour communiquer avec la carte on utilise le protocole Serial Wire Debug.

Le Serial Wire Debug (SWD) corresponds à un protocole de communication comprenant deux fils permettant le debug sur votre carte ARM. Le protocole utilise 2 pins pour le debug et une pin pour la trace. La trace est utilisé par le moniteur série pour lire les printf. Le SWD est une alternative au JTAG. Le SWD remplace le JTAG chez ARM. Il a été réalisé car ce protocole utilise deux fois moins de pins pour communiquer ave cla carte que le JTAG (2 au lieu de 4).

Voici l’utilité des deux fils du protocle SWD :

  • SWDIO : bidirectionnal data line
  • SWCLK : Clock driven by the host

Avec le SWD on peut programmer la carte et recevoir les valeurs pour le moniteur série

Pour communiquer avec la carte, n utilise l’unité Intrumentation Trace Macrocell.

Disassembleur

Une fois en mode débug, on se rends compte que le programme ne déroule pas de lui même mais il faut cliquer sur le triangle vert afin de passer à l’instruction suivante. Pour charque instruction on peut avoir une vue désasemblée du code afin de savoir où le programme s’est vraiment arrêté.

Ici on peut voir que le programme est arrêté sur la ligne verte  :

Pour voir sur quelle ligne assembleur le programme est arrêté, il faut faire windows puis show view et Disassembly :

On peut voir sur la droite une page qui nous indique la ligne en assembleur pour laquelle le programme est arrêté :

Stepping

Les boutons stepping permettent de vous déplacer d’instruction en instruction afin d’éxecuter votre programme pas à pas.

 

Step into : Permet d’exécuter l’instrcution suivante et de rentrer dans les fonctions.

Step over : Permet d’exécuter entirèement une fonction en une suele fois sans devoir cliquer plusieurs fois à l’intérieur de la fonction. Permet de passer àla fonciton suivante en une instruction.

Step Return : Permet de retourner à l’instruction précédente où de sortir d’une fonction.

Instruction Stepping mode : Permet de passer d’une instruction arm à la suivante

Breakpoints

Les Breakpoints (point d’arrêt en français) permet d’arrêter le processeur ou les instructions à une certaine addresse. Ce sont des breakpoints hardware, ce qui veut dire qu’elles vont se réaliser à l’intérieur du processeur. Vous avez aussi des breakpoints software qui se réalise avec des instructions dans votre programme.  Le breakpoint hardware fonctionne avec des comparateurs.

Vous ne pouvez donc pas mettre autant de breakpoints que vous souhaitez. Certain processeurs possède que 6 comparateurs par exemple, ce qui vous limite à 6 breakpoints.

La première chose à faire est de cliquer sur windows puis Show View et Breakpoints :

Une fois clique on peut voir la fenêtre sur le Breakpoints s’ouvrir :

Pour ajouter un breakpoint il faut vous cliquiez juste à gauche du chiffre. En double cliquant on peut voir un petit logo qui indique qu’il y aura un arrêt sur cette ligne :

En cliquant sur la ligne on peut voir le breakpoint apparaissant dans la fenêtre :

On ajoute des beakpoints hardware, on ne peut donc pas  en ajouter à l’infini. Nous sommes limité par le nombre de comparateur de notre carte STM32. Ici on peut voir l’erreur que l’on obtient quand on ajoute trop de breakpoints :

Expression et variable windows

Dans le logiciel STM32IdeCube on peut facilement suivre les valeurs des variables après avoir ajouté des breakpoints et de changer ces valeurs ci-besoin.

Ici on peut voir que dans le debug mode, en passant ntore souris sur une variable on peut voir sa valeur à l’instant T.

Ceci fonctionne avec les breakpoints.

Pour afficher la page des variables, on clique sur window, Show view puis Variables :

Une fois la page des variables affichée on peut voir celle-ci avec leurs valeurs respectives.  Ceci foncitonne avec des breakpoints :

Call Stack

Le Call Stack permet de voir les erreurs que provoque notre programme lors de la compilation de celui-ci. Pour cela on a ajouté volontairement une erreur en appelant un pointeur sur une partie de la mémoire ne contenant pas d’instruction :

Ici on peut voir que le pointeur jump_addr prends la valeur de la case mémoire 0X2000008 qui est vide donc cela créer une erreur :

On peut en lançant le debug du programme que sur la gauche nous avons des erreurs. Ceci est représenté par la ligne Signal Handler. Quand vous obtenez cette ligne cela veut dire que cela créer une exception donc une erreur dans le programme. En cliquant sur swap_number() on peut voir l’erreur exacte qui nous pose problème : un appel à une fonction vide (surligné en vert)  : 

Si on veut en savoir plus sur la nature de l’erreur nous pouvons ouvrir l’analyseur de faute. Pour cela vous devez aller sur window puis Show view et Fault Analyzer :

Dans le Fautl Analyzer on peut voir les erreurs commises dans notre programme. en l’occurence pour nous ce sont des problèmes d’utilisations de la mémoire :

Data Watchpoint

Le data watchpoint permet de surveiller quand une variable est modifiée. Quand vous avez un projet assez important, vous pouvez avoir du mal à savoir où la valeur de votre variable est modifiée. La première étape pour enregistrer une variable est  d’aller sur la fenêtre breakpoints puis add Watcpoint sur le logo tout à droite :

Une pop up s’ouvre ensuite puis on ajoute la variable que l’on souhaite surveillé et si l’on souhaite surveiller la lecture ou l’écriture :

Ici on peut voir la variable someData que l’on surveille :

Vous pouvez aussi surveiller une case mémoire afin de savoir quand sa valeur change en remplaçant le nom de votre variable par la case mémoire à surveiller :