Memoire: Automatisation de La Validation Des Exemples de La STM32Cube Firmware

République Tunisienne Cycle de Formation d’Ingénieurs dans
Ministère de l’Enseignement Supérieur la Discipline Génie Electrique

et de la Recherche Scientifique ST-EN07/00
Université de Sfax Projet de Fin d’Etudes
École Nationale d’Ingénieurs de Sfax N° d’ordre : 2021/DGE-019
MEMOIRE
Présenté à
L’Ecole Nationale d’Ingénieurs de Sfax

(Département de Génie Electrique)
En vue de l’obtention
Du Diplôme National d’Ingénieur en Génie Electrique
Par
Islam MOUSSI
Automatisation de la Validation des Exemples de la STM32Cube

Firmware
Soutenu le 02 Octobre 2021, devant la commission d’examen :
M. Chokri REKIK Président
M. Hafedh ABID Rapporteur
M. Hatem TRABELSI Encadrant Académique
M. Chokri GAMMOUDI Encadrant Industriel
M. Rabie ABDAOUI Co-encadrant

A mes parents, à ma famille,
ii
Remerciements
En préambule à ce rapport, Je tiens à exprimer mes remerciements les plus sincères à tous
ceux qui ont contribué de près ou de loin dans la concrétisation de ce travail.
J’adresse tout d’abord mes remerciements les plus sincères à la société

STMicroelectronics qui m’a accueilli et m’a offert l’opportunité et l’honneur de travailler
avec l’une de ses chaleureuses équipes.
Je voudrais également exprimer ma gratitude et mon sincère respect à mes superviseurs

d’entreprise, Mme Wissem ARFAOUI et M. Chokri GAMMOUDI pour leur encadrement et
leur orientation professionnelle au cours de ce stage.
Je suis également extrêmement reconnaissante à M. Hatem TRABELSI, mon superviseur

de l’école, pour ses conseils utiles, ses suggestions, ses commentaires et sa supervision durant
ce travail, mes vifs remerciement s’adresse aussi aux membres de jury M. Chokri REKIK et
M. Hafedh ABID qui ont accepté de nous honorer de leur présence et de juger ce travail.
Je voudrais également remercier M. Rabie ABDAOUI, M. Mohamed Ali Hachicha et

tous les membres de l’équipe Test Framework auxquels j’ai appartenu et avec qui j’ai
travaillé tout au long ce stage.
Dernier et le plus important, je voudrais exprimer mon amour et ma profonde gratitude à

ma mère, à ma famille, pour leur soutien et leurs encouragements. Je voudrais remercier tous
mes chers amis et personnes extraordinaires que j’ai rencontrés au cours de ce stage.
iii
Table des matières
Remerciements ...................................................................................................................... iii

Table des figures .................................................................................................................... vii
Liste des acronymes....................................................................................................................x
Introduction Générale .................................................................................................................1
Chapitre 1 : Présentation du cadre générale du projet......................................................3

Introduction .........................................................................................................................4
1. Présentation de l’entreprise d’accueil ..................................................................................4
1.1. STMicroelectronics Tunis ............................................................................................7

1.2. L’équipe Test Framework ............................................................................................8
2. Etat de l’art ..........................................................................................................................9
3. Présentation du projet........................................................................................................ 11
3.1. Contexte du projet ..................................................................................................... 11

3.2. Problématique............................................................................................................ 12
3.3. Etude de L’existant ................................................................................................... 12
3.3.1. Description de l’existant ........................................................................................ 12
3.3.2 Critique de l’existant ............................................................................................. 15
4. Solution proposée.............................................................................................................. 17
4.1 Objectifs du projet ..................................................................................................... 17

4.2 Méthodologie du travail ............................................................................................ 17
Conclusion ............................................................................................................................... 18
Chapitre 2 :Etude préalable sur les microcontrôleurs et la plateforme logicielle intégré 19
Introduction ...................................................................................................................... 20
1. Généralité sur les microcontrôleurs .................................................................................. 20
2. Le microcontrôleur STM32 .............................................................................................. 21

iv
2.1. Les processeurs ARM Cortex-M .............................................................................. 23
2.2. Architecture système de STM32 ............................................................................... 24
3. Généralités sur les périphériques ...................................................................................... 25
3.1. Le périphérique ou IP……………………………………………………………….25

3.1. Les registres ........................................................................................................... 25
3.2. Les fonctionnalités du périphérique....................................................................... 26
3.3. L’horloge du périphérique ..................................................................................... 26
3.4. Interconnexion entre les périphériques .................................................................. 26
3.5. Chaine(s) du périphérique ..................................................................................... 26
4. La plate-forme logicielle intégrée ..................................................................................... 27
4.1 Vue d’ensemble de la librairie Hardware Abstraction Layer (HAL) ......................... 27

4.1.1. Fichiers HAL ......................................................................................................... 28
4.1.2. Fichiers de l’application ........................................................................................ 29
4.1.3. Processus d’opérations HAL ................................................................................. 30
4.2. Vue d’ensemble de la librairie Law Layer (LL) .................................................... 33
5. Analyse des besoins .......................................................................................................... 35
5.1. Besoins fonctionnels.................................................................................................. 35

5.2. Besoins non fonctionnels .......................................................................................... 35
Conclusion ........................................................................................................................ 36
Chapitre 3 : Mise en œuvre de l’automatisation des exemples ...................................... 37
Introduction ............................................................................................................................. 38
1. Exigences logicielles et matérielles .................................................................................. 38
3.1. Ressources matérielles .............................................................................................. 38

1.1.1. Autoboard .............................................................................................................. 39
1.1.2. ST-Link.................................................................................................................. 42
1.1.3. La passerelle USB/I2C .......................................................................................... 42
3.2. Ressources logicielles ............................................................................................... 44
2. Description de la plateforme de test ................................................................................. 46
3. Catégories d’automatisation .............................................................................................. 50
3.1. Automatisation de la catégorie 1 ............................................................................... 50
v
4. Mise en place d’une plateforme de validation basée à l’Autoboard et plateforme jenkins:54
4.1. L’outil Jenkins ........................................................................................................... 58

4.2. Génération du rapport de validation .......................................................................... 58
5. Rentabilité de l’Automatisation ........................................................................................ 60
Conclusion ........................................................................................................................ 61
Conclusion générale ............................................................................................................. 62
Bibliographie 63
Annexe 1 64
Annexe 2 65
Annexe 3 66
Annexe 4 67
vi
Table des figures
Figure 1.1 : logo de STMicroelectronics ..................................................................................4
Figure 1.2 : Gamme de produits de STMicroelectronics ......................................................... 5
Figure 1.3 : Marchés ciblés par ST ............................................................................................... 5
Figure 1.4 : Site tunisien de STMicroelectronics ..................................................................... 7
Figure 1.5 : Position de la division MCD dans ”STMicroelectronics” .................................... 8
Figure 1.6 : DIE interne d’un MCU STM32F103 ..................................................................... 9
Figure 1.7 : Le portefeuille STM32 ......................................................................................... 10
Figure 1.8 : Processus de validation des microcontrôleurs STM32 ........................................ 14
Figure 1.9 : Vérification FPGA ................................................................................................... 14
Figure 2.1 : Matrice de bus interne STM32 ............................................................................. 22
Figure 2.2 : ARM Cortex-M33 ................................................................................................ 24
Figure 2.3 : Structure d’un exemple modèle de l’architecture HAL .......................................31
Figure 2.4 : Séquence typique de traitement en mode bloquant .............................................. 31
Figure 2.5 : SEQUENCE typique de traitement en mode d’interruption (non-bloquant) .......32
Figure 2.6 : Séquence typique de traitement en mode DMA (non-bloquant) ........................ 33
Figure 3.1 : Séquence typique de traitement en mode DMA (non-bloquant) ......................... 39
Figure 3.2 : Figure 3.2 : Carte de validation automatique ....................................................... 39
Figure 3.3 : Différents blocs de l'AutoBoard........................................................................... 41
Figure 3.4 : Fonctionnalités de la carte de validation automatique .........................................41
Figure 3.5 : Débogueur ST-Link ............................................................................................. 42
Figure 3.6 : Format de la trame transmise ............................................................................... 44
Figure 3.7 : Schéma de fonctionnement de l'API Autoboard_Reset () .................................... 45
Figure 3.8 : Schéma de fonctionnement de l'API Connect Pin to Channel .......................... 46
Figure 3.9 : Architecture globale ............................................................................................. 47
Figure 3.10 : Architecture d'un dépôt d'un projet STM32 ....................................................... 48
Figure 3.11 : Exemple de test d’exemples de la catégorie 1 ................................................... 51
vii
Figure 3.14 : Setup utilisé pour l’automatisation .................................................................. 55
Figure 3.15 : Cycle de processus de validation automatique ................................................ 56
Figure 3.16 : Version des codes dans Gerrit avant la vérification ........................................ 57
Figure 3.17 : Transfère vers le serveur principal .................................................................. 57
Figure 3.18 : Configuration et Exécution de Job............................................................... 57
Figure 3.19 : Outil logiciel d’intégration Jenkins .............................................................. 58
Figure 3.20 : Affichage en cas de validation de plusieurs REMAP .....................................59
Figure 3.21 : Résumé de validation ......................................................................................60
Figure 3.22 : Arborescence du Firmware ............................................................................. 64
Figure 3.23 : Structure du fichier Jenkins_config_fw.xml ................................................... 65
Figure 3.24 : Autoboard_config.xml de la carte STM32 ..................................................... 66
Figure 3.25 : Bench.xml de la carte STM32........................................................................ 66
Figure 3.26 : Config.xml d’un exemple ADC… .................................................................67
viii
Liste des tableaux
Table 2.1 : Les fichiers des pilotes HAL ........................................................................27

Table 2.2 – Les fichiers de l’application (sous le dossier user) ...................................... 29
Table 2.3 – Les fichiers des pilotes LL ........................................................................... 33
Table 3.1 : Liste des commandes reconnues par l’autoboard ......................................... 42
Table 3.2 – Description des scripts d’automatisation ..................................................... 47
Tableau 4.1 : Temps de validation avant et après l’automatisation ................................ 60
ix
Table des acronymes
ADC: Analog to Digital Converter
API: Application Programming Interface
ARM: Advanced RISC Machine
ART: Adaptive Real-Time
CMSIS: Cortex Microcontroller Software Interface Standard
CPU: Central Processing Unit
DAC: Digital to Analog Converter
DUT: Device Under Test
DVS: Dynamic Voltage Scaling
DMA: Direct Memory Access
FPGA: Field Programmable Gate Array
FIFO: First In First Out
GPIO: General Purpose Input Output
HAL: Hardware Abstraction Layer
I2C: Inter Integrated Circuit
IEEE: Institute of Electrical and Electronics Engineers
LL: Low Layer
MCU : Micro Controller Unit
MCD : Micro Controller Devision
MSP: Microcontroller Support Package
MEMS: Micro-Electro-Mechanical System
PVD: Programmable Voltage Detector
RNG: Random number generator
SRAM: Static Random-Access Memory
USB: Universal Serial Bus
VCP: Virtual Com Port
0
Introduction Générale
Ces dernières années, les microcontrôleurs ont connu un développement remarquable. Ils sont
devenus le principe de base des appareils électroniques utilisés dans notre quotidien. Le succès
indélébile des microcontrôleurs est dû à leur flexibilité, Réduisez la taille et le coût sont les défis
des fabricants de ces outils. Par conséquent, le marché des semi-conducteurs est développé ; les
investisseurs sont déjà accros. STMicroelectronics, l’un des fabricants de semi-conducteurs et le plus
célèbre au marché mondial, a pu à son tour faire une recherche permanente sur des nouvelles
méthodes d’amélioration pour persister devant la compétitivité du marché internationale et main-
tenir ou même améliorer son classement mondial actuel. Les tests des validations fonctionnelles et
exhaustives sont les liens inévitables dans le cycle de vie de n’importe quel produit. D’où la
vérification fonctionnelle prise en charge le test de tous les drivers fournis par STMicroelectronics
et du microcontrôleur lui-même. Puis, la validation exhaustive pour tester le fonctionnement
intérieur niveau registre et le développement d’un microcontrôleur qui est une étape complexe et
extrêmement importante. En production de masse, ce test doit être effectué pour assurer la cohérence
entre le cahier des charges (la spécification) et les produits fabriqués. Afin d’optimiser sa gestion
des ressources humaines, d’améliorer la qualité de ses microcontrôleurs et également de garantir
le temps de production le plus court pour répondre aux exigences de temps du client,
STMicroelectronics a choisi d’ automatiser les scénarios des tests de validation fonctionnelle et
exhaustive de ses microcontrôleurs qui passent en moyenne une semaine avec le processus manuel
pour valider un périphérique.
C’est dans ce cadre que s’inscrit notre projet de fin d’étude dont l’objectif est l’automatisation
de la validation des exemples et des applications d’une nouvelle famille de la carte STM32.
C’est pourquoi, l’automatisation sera un bénéfice important non seulement en termes de
réduction du temps de validation mais également en termes de frais.
1
Ce présent rapport décrit mon travail sur ce projet et il est divisé en trois chapitres. Tout
d’abord, nous présenterons cadre générale du sujet ainsi que de l’entreprise. Ensuite, nous
présenterons les notions de bases sur lesquelles porte notre projet, puis nous détaillerons la
solution proposée que nous nous en servons par la suite pour atteindre les objectifs déjà
définis dès le premier chapitre et on se termine avec une conclusion générale.
2
Chapitre 1
Présentation du cadre générale du projet
3
Introduction :
Pour améliorer la productivité, chaque entreprise a intérêt à réduire à la fois le temps et les
efforts consacrés à chaque produit. Afin d’en s’assurer, certaines entreprises ont tendance à
automatiser toute tâche répétitive, fastidieuse durant leur processus de production.
Dans ces circonstances, STMicroelectronics m’a confié ce projet pour automatiser des
exemples d’applications s’exécutant sur un microcontrôleur STM32. Dans ce chapitre, je
présenterai STMicroelectronics, la société qui m’a hébergé pendant mon stage, le contexte du
stage et les objectifs du travail.
1. Présentation de l’entreprise d’accueil :

En juin 1987, SGS Microelettronica (Italie) et Thomson Semi-conducteurs (France) ont été
fusionné donnant naissance à SGS-Thomson microelectronics qui a été renommé
STMicroelectronics en mai 1998.
Figure 1.1: logo de STMicroelectronics
Maintenant, STMicroelectronics est un leader mondial qui développe, fabrique et

commercialise des puces électroniques, fournissant ainsi des solutions innovantes de
semiconducteurs destinées à un grand nombre d’applications microélectroniques.
Le spectre des produits électroniques contient principalement 6 familles qu’on énumère dans
la liste suivante.
— Circuits intégrés dédiés automobile.
— Transistors de puissance et transistors radio fréquence.
— Circuits intégrés analogique et audio.
— Captures et MEMS (Micro-Electro-Mechanical System).
4
— Circuits mémoire, microprocesseurs et microcontrôleurs
— ASICs (Application-Specific Integrated Circuit) basés sur ST technologies propriétaire.
La figure 1.2 montre la gamme de produits industrialisés par ST.
Figure 1.2: Gamme de produits de STMicroelectronics [2]
Avec une Portefeuille offrant une complémentarité aux marchés finaux cible, ST vise ainsi
plusieurs secteurs tels que l’Internet des objets, la téléphonie mobile, l’industrie et
l’automobile. La figure 1.3 décrit les champs d’application de ST.
Figure 1.3: Marchés ciblés par ST [2]
Avec environ 46000 employés dans le monde, 11 sites de fabrication et Plus de 80 bureaux de
vente et de marketing, ST est à la pointe de l’innovation technologique avec environ 7400
personnes travaillant dans la recherche et le développement. Au service de plus de 100 000
clients à travers le monde, ST a réalisé un chiffre d’affaires de 9.56 milliards de dollar
américain en 2019, avec une croissance de 15.8 % d’une année à l’autre.
5
STMicroelectronics est présent dans plusieurs pays du monde, notamment en Tunisie, où
la société a continué de renforcer son activité grâce à la disponibilité d’un grand nombre
d’ingénieurs tunisiens.
1.1. STMicroelectronics Tunis :

Le site tunisien de ST illustré dans la figure 1.4 est l’un des sites les plus diversifiés de la
société en termes d’expertise avec plus de 220 employés travaillant sur l’ingénierie, la
conception, les applications et le support. Dirigé par M. Mohamed BEN AHMED, Il a été
fondé en 2001 dans le parc technologique et de télécommunication El-Ghazala à Tunis.
ST Tunis comprend la division microcontrôleur (MCD : Micro-Controller Division) dans
laquelle j’ai intégré l’équipe ” Test Framework”.
Figure 1.4: Site tunisien de STMicroelectronics
Les principales activités attribuées du site de Tunis sont :

— Le développement et la conception des applications à base des microcontrôleurs ST.
— Vérification et validation des microcontrôleurs ST
La division ”MCD” est destinée à la conception des microcontrôleurs, des plateformes de dé-
monstration et des solutions pour l’utilisation grand public avec des produits compétitifs et
innovants, en outre, elle s’occupe de la validation des outils de développement logicielles et
électroniques, des supports techniques des clients et de la validation des microcontrôleurs 8
bits et 32 bits. Cette division appartient au groupe ”MMS” (Microcontroller, Memory and
Security) comme la montre la figure 1.5.
7
Figure 1.5: Position de la division MCD dans ”STMicroelectronics” [2]
1.2. L’équipe Test Framework :

Test Framework ou également STM32 FPGA validation and test automation, est une équipe
dirigée par Mme Wissem ARFAOUI. Elle est responsable de la planification, de la
surveillance, du contrôle des activités de test du microcontrôleur STM32 et de
l’automatisation de la validation de la STM32Cube Firmware. Multidisciplinaire et au cœur du
développement logiciel et matériel, elle joue un rôle extrêmement important dans les processus
d’industrialisation et de marketing des microcontrôleurs STM32.
Ses principales missions se résument comme suit :
— La validation de tous les périphériques internes des MCUs STM32 sur FPGA, le rapport
des bugs à la conception, leur suivi et leur résolution.
— Le développement et la validation des exemples HAL (Hardware Abstraction Layer),
LL (Law Layer) et MIX (conjonction entre LL et HAL) de la STM32Cube firmware,
destinée aux développeurs d’applications embarquant un MCU STM32.
8
— L’analyse, la conception, la mise en œuvre et l’exécution des scénarios et des
procédures de tests ainsi que la configuration et la gestion du processus d’intégration
continue.
— Le portage, le test et la validation des exemples, des applications et des démonstrations
sur EWARM, MDK-ARM et SW4STM32 pour les mettre à disposition sur des
différents tool-chains.
2. Etat de l’art :
STM32 est une large gamme de microcontrôleurs divisés en quatorze familles, chacune avec
ses caractéristiques. ST a commencé la production de ce portefeuille sur le marché en 2007,
en commençant par la série STM32F1, qui est encore en développement. La figure 1.6 illustre
la puce interne ”die” d’un microcontrôleur STM32F103, l’un des MCU STM32 les plus
répandus.
Figure 1.6: DIE interne d’un MCU STM32F103 [1]
Tous les microcontrôleurs STM32 possèdent un cœur Cortex-M, ainsi que certaines
fonctionnalités distinctives de ST, est conçue pour offrir de nouveaux degrés de liberté aux
utilisateurs de MCU. Elle propose des produits combinant des performances très élevées,
des fonctionnalités temps réel, le traitement du signal numérique, un fonctionnement basse
consommation et basse tension et une connectivité, tout en maintenant une intégration
complète et une facilité de d´développement. Basé sur des standards de l’industrie et
accompagné d’un vaste choix d’outils et de logiciels, STM32 est le choix idéal, aussi bien
pour de petits projets que pour des plates-formes entières.
9
Comme déjà mentionné, STM32 est une gamme de produits assez complexe, qui couvre
quatorze familles de produits. La figure 1.7 résume le portefeuille actuel de STM32. Le dia-
gramme regroupe les familles en trois groupes de macros : les microcontrôleurs hautes per-
formances, le grand public, les plates-formes ultra basse consommation et les sans fil.
Figure 1.7: Le portefeuille STM32 [3]
✓ Les microcontrôleurs hauts performances sont les microcontrôleurs STM32 dédiés

aux applications multimédias intensives en ressources CPU.
Ce sont des MCU basés sur Cortex-M3/4/7, avec des fréquences d’horloge maxi-
males allant de 120 MHz (STM32F0xx) à plus de 200 MHz (STM32F7xx).
Tous les MCU de ce groupe fournissent ART Accelerator, une technologie ST qui
permet une exécution sans attente depuis la mémoire flash.
✓ Les MCU grand public sont développées pour des applications sensibles au coût,
où le coût de la MCU doit être même inférieur à un dollar et où l’espace est une
contrainte forte. Dans ce groupe, nous pouvons trouver des MCU basés sur Cor-
10
texM0/3/4, avec des fréquences d’horloge maximales allant de 48 MHz
(STM32F0xx) à plus de 72 MHz (STM32F1xx et STM32F3xx).
✓ Le groupe Ultra Low Power contient les familles de microcontrôleurs STM32
destinées aux applications à faible consommation utilisées dans les périphériques
alimentés par batterie qui doivent réduire la consommation totale d’énergie à des ni-
veaux faibles pour une durée de vie prolongée de la batterie. Dans ce groupe, nous
pouvons trouver à la fois des MCU basés sur Cortex-M0, pour des applications
sensibles au coût, et des microcontrôleurs basés sur Cortex-M4 avec Dynamic
Voltage Scaling (DVS), une technologie permettant d’optimiser la tension interne du
CPU en fonction de sa fréquence.
✓ Le groupe sans fil est celui des MCUs offrant des solutions de connectivité sans fil
fiables et économiques afin de connecter des objets intelligents à Internet et au
cloud, ou plus largement à l’Internet des objets (IoT : Internet of Things).
Remplaçant ainsi les câbles et les connecteurs par des communications sans fil a`
courte portée. Apportant une connectivité RF (Radio Fréquence) au portefeuille
STM32, le microcontrôleur STM32WB intègre un système radio 2.4 GHz prenant
en charge les protocoles de communications Bluetooth 5 basse consommation
(BLE) et IEEE
802.15.4. En associant le cœur Cortex-M4 de hautes performances à un cœur Cor-
tex-M0 + dédié au traitement des fonctions réseau, le nouveau système sur puce
STM32WB tire pleinement parti des possibilités technologiques des
microcontrôleurs ultra-basse consommation de ST pour conjuguer des
performances RF élevées pour une durée de vie de batterie allongée.
3. Présentation du projet :
3.1. Contexte du projet :

Actuellement, le marché des semi-conducteurs présente une forte concurrence vu le nombre
important de sociétés exerçant dans ce domaine. De plus, chaque société veut répondre aux
besoins de ses clients, ainsi l’avancée technologique dans ce marché est très rapide et de
nouveaux produits envahissent le marché à un rythme très important. En effet, il existe une
11
large gamme diversifiée de microcontrôleurs qui répondent précisément aux exigences en
termes de performance, consommation d’énergie, robustesse et la technologie utilisée.
Afin de garantir la qualité des produits, les microcontrôleurs doivent passer par la phase de
validation, qui est une phase cruciale avant la production en masse des microcontrôleurs.
Cette validation peut être effectuée sur FPGA ou sur Silicium et assure une détection précoce
des anomalies ou à l'intégration au niveau SoC. Lors de détection des anomalies un rapport se
génère et déclenche une investigation suivie d’une correction.
3.2. Problématique
Comme citées précédemment, la phase de validation permet d’assurer le bon fonctionnement
des microcontrôleurs et de gagner le coût énorme de correction. En outre, suite à la révolution
technologique dans le domaine de la microélectronique, la cadence de fabrication des
nouveaux produits par la société STMicroelectronics ne cesse d’augmenter vu la haute qualité
et la richesse de ses produits. Également, l’augmentation de la complexité des produits exigée
par les besoins des clients rend la validation manuelle de plus en plus pénible, inefficace et
nécessite beaucoup de temps. En effet, exécuter manuellement les tests de chaque périphérique
sur chaque produit et à chaque modification du concepteur, est vraiment infructueux et long
vu le nombre important des scénarios des tests. Donc face à cette situation, l’équipe de
validation s’évertue à automatiser au maximum les tests des différents périphériques et à
réutiliser le software des tests indépendamment du produit à tester.
3.3. Etude de L’existant :
3.3.1. Description de l’existant :

La validation du microcontrôleur passe par un ensemble des étapes résultant à la
production en masse du prototype du microcontrôleur.
Ce flux commence chez les marqueteurs, qui, selon les besoins des clients, fournit un cahier
de charges décrivant, selon le produit, le microprocesseur à utiliser ainsi que les différents
périphériques à intégrer tout en précisant la version adoptée pour chaque périphérique.
La plate-forme STM32 offre plusieurs avantages pour les développeurs embarqués, en
effet ce sont des MCU basés sur Cortex-M et donc plusieurs outils sont offerts sur le marché
aux clients pour développer leurs applications. ARM est devenu une sorte de standard dans le
12
monde embarqué et 50 milliards d’appareils vendu d’ici 2014 est une garantie forte
qu’investir sur cette plateforme est un bon choix. De plus les MCU STM32 sont livrés avec
un chargeur de démarrage intégré (bootloader), qui permet de reprogrammer la mémoire flash
interne à l’aide de certains périphériques de communication (USART, I2C, SPI, etc.). STM32
est un portefeuille assez vaste, et le plus important et merveilleux, c’est que chaque nouvelle
famille produite n’est livrée qu’avec un ensemble complet d’exemples, applications et dé-
monstrations, qu’on appelle désormais Firmware, fonctionnant sur les différentes cartes de
développement STM32 Nucléo, Evaluation et Discovery. L’annexe 1 montre l’architecture
d’une Firmware.
Une fois l’équipe SoC fournit la conception de la RTL, l’équipe intégration FPGA utilise ce
RTL comme support afin de générer la NETLIST qui sera implémenté par la suite sur
l’FPGA.
Pour garantir le bon fonctionnement de microcontrôleur, l’équipe de validation lance une série
des tests dans le but et de détecter les problèmes de conception ou d’intégration. Dans le cas
du succès des tests, le microcontrôleur passe à la validation Silicium, mais dans le cas con-
traire une correction de la conception s’impose.
La figure 1.8 décrit le flux de validation des microcontrôleurs STM32.
➢ Vérification FPGA
La vérification FPGA consiste à vérifier le bon fonctionnement des périphériques du
microcontrôleur décrit dans le fichier de spécification matérielle. Cette description mène à la
génération de NETLIST qui sera par la suite implémenté sur l’émulateur FPGA. Une série de
tests assure la détection des anomalies et exige une correction en cas d’erreurs. La figure 1.9
présente le flux de vérification FPGA.
Cette étape est réalisée par l’équipe « Vérification FPGA », elle est composée de 3 sous
étapes :
✓ La documentation sur le produit : C’est la première étape dans le processus de
vérification FPGA, Cette documentation présente différents types de documents tels
que, le manuel de référence, les documents SoC et RTL. Ces documents apportent des
données sur l’architecture interne du microcontrôleur ainsi que les caractéristiques des
périphériques existants dedans. Ces caractéristiques permettent de définir les points à
tester et les contraintes à éviter lors du développement des différents scénarios.
13
Figure 1.8: Processus de validation des microcontrôleurs STM32
Figure 1.9: Vérification FPGA
✓ Le développement des scénarios de test : Consiste à développer des nouveaux

drivers s’il s’agit d’un nouveau périphérique, modifier le driver si le périphérique a
14
subi une amélioration ou modification au niveau des fonctionnalités et finalement
Développer les scénarios de test tout en couvrant les fonctionnalités du périphérique.
✓ La génération du rapport de validation et investigation : Lors de l’exécution des
différents tests un rapport sera généré pour fournit des informations sur Le nombre de
tests échoués, Le nombre de test passés et La localisation des erreurs. Ces différentes
informations permettent aux ingénieurs de validation ainsi que les différentes équipes
travaillant sur le périphérique de corriger l’erreur et reporter les modifications
nécessaires au niveau de la conception.
➢ Validation sur Silicium
La validation sur Silicium est une phase de validation destinée pour tester le fonctionnement
des prototypes des microcontrôleurs ainsi qu’autres tests physiques tels que les tests
thermiques, d’immunité électromagnétique et de consommation d’énergie.
Une modification et correction de la conception des modules sera effectuée lors de détection
des différentes anomalies ou d’un comportement insatisfaisant. Différentes versions du proto-
type du microcontrôleur seront générées avant d’aboutir à une version finale ayant réussi à
passer tous les tests de validation sur Silicium.
3.3.2 Critique de l’existant :

La phase de validation FPGA et Silicium des microcontrôleurs STM32 est une phase
primordiale lors de la fabrication des produit STM32. En effet, ce processus requiert beaucoup
de temps, énormément d’argent et dur labeur pour se laisser mener à bien. En outre la
validation actuelle des périphériques sur FPGA ou Silicium est répartie sur plusieurs équipes,
ce qui a engendré une diversité de procédures de test ainsi que des problèmes de
synchronisation entre les différents projets.
Les majeures limitations que la plateforme de validation actuelle présente sont les suivantes :
✓ Problèmes de portabilité : Le software de test des projets de validation actuels, se
limite aux fonctionnalités des périphériques proposées dans chaque famille d’un pro-
duit STM32 spécifique. Un même périphérique peut avoir plusieurs tests qui semblent
bénéfiques pour le débogage et l’investigation par l’ingénieur de validation
responsable, mais tout changement de la famille de produit engendre une nécessité de
portage du software et ainsi une perte de temps. D’où le besoin d’un software
générique,
15
qui rassemble le maximum possible de caractéristiques et qui peut être modifié
aisément sans provoquer des différences majeures.
✓ Insuffisance de couverture des fonctionnalités des périphériques : La validation
des périphériques est faite pour assurer la couverture d'un pourcentage maximum des
caractéristiques du périphérique, mais cela sera impossible en utilisant l’aspect manuel
des tests. En effet, plusieurs fonctionnalités seront non testées ce qui affaiblit par la
suite le processus d’amélioration des performances du périphérique. D’où l’exigence
d’avoir un software couvrant le maximum de fonctionnalités est d’une importance
critique pour garantir la satisfaction des utilisateurs des produits STM32 ainsi que
pour une amélioration continue de la conception.
✓ Contraintes d’investigation : La méthode de validation actuelle montre des limites
dans la phase d’investigation. Cette phase suit la phase d’exécution des tests, et exige
un rapport détaillé sur les causes des erreurs détectées. En effet, les rapports de
validation actuelle ne renseignent généralement que sur le comportement du test
(FAIL/PASS), ils ne présentent pas suffisamment de détails pour permettre une
détection des erreurs rapide. D’où, il faut consacrer beaucoup de temps et d’effort
pour investiguer les causes des erreurs.
✓ Scenarios de test non flexibles : Les scénarios de tests actuels ne sont pas
suffisamment dynamiques ce qui limite les performances des tests. En effet, certaines
fonctionnalités des périphériques possèdent plusieurs paramètres et le fait de tester
quelques paramètres parmi tout peut masquer des disfonctionnements ou des
limitations dans les drivers utilisés dans les tests.
✓ Aspect manuel des tests : La validation actuelle nécessite une intervention manuelle
continue. Des interconnexions filaires sont requises pour déclencher le réveil du
système. La vérification de la conformité des signaux est assurée par la visualisation
de ces derniers sur un oscilloscope et une éventuelle comparaison par l’allure du
signal attendu. Toutes ces pratiques ralentissent le processus de validation et
augmentent le taux d’erreur.
16
4. Solution proposée :
Pour la plateforme de validation actuelle toutes les contraintes vécus précédemment
sont un frein tangible à son amélioration mais ces derniers pourraient être résolus par
l’utilisation de l’automatisation.
Ainsi, l’automatisation permet de réduire le temps de validation, augmenter le taux de
couverture des fonctionnalités de chaque périphérique, offrir un support détaillé pour la
phase d’investigation et se débarrasser de l’aspect manuel. Cette approche est considérée
comme la meilleure solution pour notre projet.
4.1 Objectifs du projet :

L’objectif principale de ce projet et de concevoir une plateforme de validation
automatique des tests des périphériques tout en validant l’environnement HAL, LL, MIX.
Afin de remédier aux insuffisances constatées dans l’environnement de validation manuel
et améliorer la méthode de validation, nous avons procédé à l'adoption de mesures
suivantes :
✓ Préparer des scénarios de tests éliminant toutes les interventions manuelles et
réduisant le temps de validation de plusieurs jours à quelques minutes.
✓ Lancer tous les tests déjà développés d’une façon automatique et sans aucune
intervention externe.
✓ Générer automatiquement les rapports de validation contenant les résultats des
tests.
4.2 Méthodologie du travail :

Nous avons divisé le travail en petites tâches liées à des dates limites afin de faciliter le
déroulement du travail et contrôler le temps mis pour le projet entier.
➢ Tâche 1 : Se familiariser avec l’environnement de validation manuel
Cette tâche est primordiale pour se familiariser avec l’environnement de validation actuel
(Software + Hardware), il faut lancer les tests d’une façon manuels et assurer le bon
fonctionnement.
➢ Tâche 2 : Etude de faisabilité d’automatisation des différents tests manuels existants.
17
➢ Tâche 3 : Concevoir l’environnement de validation automatique
Mise en place de l’environnement d’automatisation hardware et la modification de
l’architecture software pour supporter les nouvelles implémentations.
➢ Tâche 4 : Implémentation des modifications software pour les différents tests.
Préparer des scénarios de tests éliminant toutes les interventions manuelles et réduisant le
temps de validation et générer automatiquement les rapports de validation contenant les
résultats des tests
Conclusion
Ce premier chapitre constitue une étape primordiale pour décrire le cadre général du projet,
dont une présentation de l’entreprise d’accueil, du cahier des charges et aussi des attentes ont
été détaillées, pour mettre le projet dans son contexte général.
Le chapitre suivant va être consacré à la description des différentes parties qui définit
l’environnement de travail.
18
Chapitre 2 :
Etude préalable et analyse des besoins
19
Introduction :
Afin de pouvoir bien cerner les différents aspects de notre projet, il est indispensable de recourir à
certaines notions théoriques et d’analyser certaines informations existantes.
Tout d'abord, nous fournissons une vue d'ensemble du microcontrôleur, puis mettons en évidence
les caractéristiques du microcontrôleur STM32. Dans un deuxième temps, nous nous pencherons
sur les périphériques à valider automatiquement pour connaitre les contraintes de validation qui
ont amené à concevoir la nouvelle plateforme de validation. Enfin, une analyse des besoins sera
élaborée avec les spécifications fonctionnelles et non fonctionnelles pour justifier le travail qui
sera réalisé.
1. Généralité sur les microcontrôleurs :

Le microcontrôleur est un circuit intégré considéré comme un mini-ordinateur conçu pour créer
des applications spécifiques utilisées dans les systèmes embarqués. Il intègre dans un même
boitier "système sur une puce" un microprocesseur, des mémoires et des périphériques
d’entrées/sorties.
Il existe plusieurs types des microcontrôleurs, qui différent suivant la vitesse de leur processeur et
par Le choix des périphériques installés. Les principales caractéristiques d’un microcontrôleur
sont :
✓ Un microprocesseur ou unité centrale de traitement est un circuit qui exécute les
instructions et traite les données des programmes. Il est caractérisé par l’architecture
Harvard ou Von Neumann, par le mode de jeu d’instruction RISC ou bien CISC et par la
longueur maximale des mots binaire (8 bits, 16 bits, 32 bits, etc.) qu’il peut échanger avec
la mémoire et les E/S.
✓ Une mémoire morte (ROM) ou mémoire non volatile contient le programme à exécuter. Il
existe plusieurs types de ROM tels que l’EPROM, l’EEPROM, Flash etc.
✓ Une mémoire vive (RAM) ou mémoire volatile pour stocker temporairement des données.
✓ Un oscillateur pour le cadencement. Il peut être réalisé avec un quartz, un circuit RC ou

encore une PLL.
➢ Des périphériques pour exécuter de nombreuses tâches spécifiques, tels que :
20
✓ TIMER ou bien compteur/temporisateur permet de compter le nombre d'impulsions d'hor-
loge interne ou le nombre d'événements externes.
✓ Liaison série asynchrone ou synchrone assure la transmission des données. Il existe plu-
sieurs types d’interface de communication comme UART, SPI, I2C et CAN.
✓ Convertisseur analogique numérique (ADC)
✓ Convertisseur numérique analogique (DAC)
✓ Modulation de largeur d'impulsion (PWM) permet de convertir une valeur numérique en
une valeur analogique proportionnelle.
✓ L'accès direct à la mémoire (DMA) assure le transfert direct des données sans
l’intervention de microprocesseur.
✓ Contrôle de puissance (PWR) pour augmenter la flexibilité dans la gestion du mode
d'alimentation et réduire la consommation globale de l'application.
Le microcontrôleur apparaît comme un système performant avec un haut taux d’intégration, une
faible consommation, une mise en œuvre plus simple et un coût réduit.
Dans la suite nous présentons les microcontrôleurs développés par la société STMicroelectronics
qui sont très répandu dans le milieu industriel.
2. Le microcontrôleur STM32 :
STM32 est un système sur puce (SoC) qui consiste en une matrice de bus AHB de 32 bits qui
établit des interconnexions entre maitres et esclaves. En gérant l'arbitrage d'accès entre maitres,
cette architecture fournit l'accès d'un maitre à un esclave, permettant un accès simultané et un
fonctionnement efficace même lorsque plusieurs périphériques fonctionnent simultanément.
La figure 2.1 montre l'architecture système d'un STM32 embarquant un assortiment de cellules
autour d'un cœur ARM Cortex-M.
La matrice de bus convertit l’interface d’interconnexion de bus Harvard interne du

processeur en trois interfaces :
— S0 : I-CODE Cible principalement la mémoire programme : Ce bus est utilisé par le
noyau pour la lecture des instructions. Les cibles de ce bus sont la mémoire flash in-
terne, SRAM1, SRAM2 et les mémoires externes via QUADSPI ou le FMC.
21
Figure 2.1: Matrice de bus interne STM32
— S0 : I-CODE Cible principalement la mémoire programme : Ce bus est utilisé par le

noyau pour la lecture des instructions. Les cibles de ce bus sont la mémoire flash in-
terne, SRAM1, SRAM2 et les mémoires externes via QUADSPI ou le FMC.
— S1 : D-CODE Cible principalement la mémoire programme : Ce bus est utilisé pour
l’accès aux données et au débogueur. Les cibles de ce bus sont la mémoire flash
interne, SRAM1, SRAM2 et les mémoires externes via QUADSPI ou le FMC.
— S2 : System Principalement pour la RAM et les périphériques, ce bus est utilisé pour
accéder à des données situées dans un périphérique ou une zone mémoire RAM. Les
cibles de ce bus sont les mémoires SRAM internes, les bus AHB1, APB1, APB2,
AHB2 et les mémoires externes via l’OCTOSPI ou le FSMC.
D’autres bus sont inscrits dans la matrice système, tels les DMA-BUS (S3, S4), les cibles de
ce bus sont les périphériques SRAM1 et SRAM2, les périphériques connectés aux AHB1,
APB1, APB2 et AHB2 et les mémoires externes via OCTOSPI ou FSMC.
22
2.1. Les processeurs ARM Cortex-M :
L’architecture ARM pour les processeurs existe depuis 1990 et se caractérise par une architecture
simple et à faible consommation. Elle propose trois familles différents développées par ARM Ltd
tels que la famille Cortex-A (Application) destinée au marché des téléphones, digital-TV et ta-
blettes, la famille Cortex-R (Real-time) destinée au temps réel et la famille Cortex-M (MCU) des-
tinée au domaine de système embarqué.
Cortex-M est une famille de cœurs physiques (Cortex-M0, M1, M3, M4, M7 et M33) conçus pour
être davantage intégrés aux dispositifs en silicium spécifiques au fournisseur pour former un
microcontrôleur fini. Le fonctionnement d'un cœur n'est pas seulement défini par son architecture
ARM associée (Armv6-M, Armv7-M et Armv8-M), mais également par les périphériques intégrés
et les capacités matérielles définies par le fabricant de silicium.
A titre d’exemple nous citons les principales caractéristiques du Cortex -M33 sont :
✓ Une architecture RISC 32 bits, architecture Harvard.
✓ Une architecture Armv8-M, Pipeline 3 étapes avec prédiction de branchement.
✓ Floating-point unit simple précision et instructions entières SIMD, utilisées pour améliorer
les performances des algorithmes DSP.
✓ Memory Map est un espace d'adressage mémoire de 4Go standardisé commun à tous les
cœurs Cortex-M et organisé en plusieurs sous-régions avec différentes fonctionnalités
logiques.
✓ Bit-Banding est la capacité de mapper chaque bit d’une zone de mémoire donnée à un mot
dans la région de mémoire de Bit-Banding alaisée, permettant l'accès atomique à ce bit.
✓ Thumb-2 est utilisé pour donner plus de largesse au jeu d’instruction, par étendant le jeu
d'instructions limité de 16 bits de Thumb avec des instructions supplémentaires de 32 bits.
✓ Memory Protection est la mémoire en charge de l'assignation des attributs de sécurité et de
privilèges ainsi que des autorisations d'accès aux instructions et aux demandes de données
initiées par le noyau.
✓ Trust zone est une sécurité matérielle intégrée au cœur des microcontrôleurs. La
technologie réduit le potentiel d'attaque en isolant le micrologiciel de sécurité critique et les
informations privées du reste de l'application. Le STM32L5 est le premier MCU STM32
basé sur l'architecture Armv8-M avec la sécurité Trust zone.
La figure 2.2 montre les différentes caractéristiques du cortex-M33.
23
Figure 2.2: ARM Cortex-M33
2.2. Architecture système de STM32 :
Les microcontrôleurs STM32 de STMicroelectronics fournissent une vaste gamme de

périphériques autour du cœur d’ARM Cortex-M, allant du simple GPIO (port d’entrée-sortie
généraliste) et interface de communication série synchrone (SPI) ou asynchrone (RS232) aux
interfaces aussi complexes que l’USB, Ethernet ou HDMI. Ces périphériques sont organisés sur
plusieurs groupes tels que :
✓ Les périphériques système ou bien system IP tels que le cortex, les mémoires (SRAM, la
mémoire flash etc.), les bus de communication AXI (Advanced Extensible Interface),
AHB (Advanced High-performance Bus) et APB (Advanced Peripheral Bus).
✓ Les périphériques analogiques comme l’ADC, DAC et COMP, qui permettent la
génération et l’acquisition des signaux analogiques.
✓ Les périphériques de communication I2C, SPI, USART, CAN etc. Ces périphériques sont
utilisés dans des applications qui nécessitent une communication série du microcontrôleur
dans une BUS de communication.
✓ Des oscillateurs fournissant des horloges de différentes fréquences et des TIMERs pour
calculer des laps de temps bien précis.
24
Les bus permettent d’assurer la communication entre le CPU et les périphériques, il y a
différents types des bus tels que le bus AHB (Advanced High-performance Bus), le bus APB
(Advan- ced Peripheral Bus) et le bus AXI (Advanced Extensible Interface) dont chaque bus est
caractérisé par ses propres spécificités. Citons les majeures différences :
✓ AXI : Supportant une fréquence de transfert de données élevée, il relie le CPU avec les
différents types des mémoires dont la fréquence de transmission est assez élevée.
✓ AHB : Supportant une fréquence de transfert de données élevée, il relie le CPU avec les
périphériques dont la fréquence de transmission est assez élevée. La fréquence de
transmission diffère d’un produit à un autre.
✓ APB : relie le CPU avec des périphériques nécessitant une fréquence de transmission
moins élevée.
La variété des fréquences de ces bus est assurée par des diviseurs de fréquence à l’issue du
bus AHB et AXI.
La diversité de ces bus assure une consommation optimale de courant tout en maintenant les
performances requises pour l’application.
3. Généralités sur les périphériques

Un périphérique ou encore IP (INTELLECTUAL PROPERTY) est un circuit électronique
dédié pour un fonctionnement bien restreint. Il est composé essentiellement d’un cœur (KERNEL)
qui est la partie fonctionnelle et d’une interface de control. Le microprocesseur contrôle le
fonctionnement du périphérique à travers cette interface. Ainsi, un périphérique peut être
numérique tel que USART, SAI, TIMER, I2C, SPI, CAN, DMA... ou analogique telque ADC,
DAC...
3.1. Les registres :

Les registres sont des cases mémoire de taille dépendant de l’architecture du
microcontrôleur en question : 8bits, 16bits, 24bits, 32bits... Ils sont utilisés pour configurer les
périphériques en un mode bien défini de fonctionnement, pour accéder aux données fournies par
les périphériques ou pour stocker des données utiles au fonctionnement des périphériques. Les
registres sont accessibles à travers l’interface de contrôle disponible pour chaque périphérique
avec une cadence bien définie. Les cases mémoire des registres se classent selon leur accessibilité
25
en lecture et écriture :
_ Cases accessibles seulement en lecture : Le contenue n’est pas modifiable.

_ Cases accessibles seulement en écriture : La lecture est interdite.
_ Cases accessibles en lecture et en écriture : La lecture et l’écriture sont permises.
3.2. Les fonctionnalités du périphérique :

Chaque périphérique se caractérise par un ensemble de services ou fonctionnalités qu’on
appelle souvent dans le milieu du travail FEATURES. Ces fonctionnalités sont limitées et bien
définies par le constructeur dans le document de spécification. La diversité des fonctionnalités
fournies par un périphérique, permet une panoplie de combinaisons possibles de configurations.
3.3. L’horloge du périphérique :

Le fonctionnement du cœur du périphérique et de son interface de control est synchronisé
par des horloges indépendantes. L’horloge de l’interface détermine la cadence d’accès aux
registres du périphérique, alors que l’horloge du périphérique lui-même détermine la cadence de
traitement des signaux qui y circulent.
3.4. Interconnexion entre les périphériques :

Un périphérique peut générer et/ou recevoir des signaux. Les signaux reçus peuvent pro-
venir d’un autre périphérique au sein du même microcontrôleur ou bien des signaux extérieurs au
microcontrôleur. Les signaux générés par les périphériques peuvent être récupérés à l’extérieur du
microcontrôleur ou servir pour être l’entrée d’autres périphériques au sein du même
microcontrôleur.
3.5. Chaine(s) du périphérique :

Un périphérique peut disposer d’une chaine ou plus. Une chaine ou bien CHANNEL en
anglais, est une voie de liaison qui permet de connecter le périphérique à un autre ou à une
entrée/sortie du microcontrôleur.
26
4. La plate-forme logicielle intégrée :
STM32Cube couvre le portefeuille de STM32 et comprend, outre que STM32CubeMX,
une plate-forme logicielle intégrée complète livrée par série (telle que STM32CubeL4 pour la
série STM32L4 et ainsi de suite) qui elle-même intègre :
— La couche d’abstraction matérielle (HAL), une interface de programmation
d’applications API STM32 garantissant une portabilité maximale à travers le porte-
feuille STM32. Le HAL est disponible pour tous les périphériques.
— Les API de couche inferieure (LL) offrent une couche rapide, légère et orientée vers les
experts, plus proche du matériel que la couche HAL.
— Un ensemble de composants middleware tels que RTOS, USB, Graphiques.
— Un ensemble complet d’exemples, montrant les performances de tous les utilitaires
logiciels intégrés ainsi qu’au matériel.
4.1 Vue d’ensemble de la librairie Hardware Abstraction Layer (HAL) :

Les pilotes HAL sont conçus pour offrir un riche ensemble d’APIs et pour interagir facile-
ment avec les couches supérieures de l’application. Chaque pilote consiste en un ensemble de
fonctions couvrant les fonctionnalités périphériques les plus courantes.
Le développement de chaque pilote est soumis à des règles communes qui normalisent la
structure du pilote, les fonctions et les noms de paramètres. Les principales caractéristiques de
HAL sont les suivantes :
— Ensemble portable inter-familles d’APIs couvrant les fonctionnalités communes des
périphériques, ainsi que des API d’extension dans le cas de fonctionnalités spécifiques.
— Prise en charge de trois modèles de programmation : polling, interruption et DMA.
— Utilisation des fonctions user-callback pour :
— Les événements d’interruption des périphériques.
— Les événements d’erreurs.
— Les API HAL (fonctions) Init / DeInit de périphériques peuvent appeler des
fonctions user-callback pour effectuer l’initialisation / la désinitialisation au niveau
du système des périphériques (horloge, GPIO, interruption, DMA).
27
— Mécanisme de verrouillage : accès matériel sécurisé pour empêcher de multiples faut
accès aux ressources partagées.
— Délai d’attente utilisé pour tous les processus bloquants.
4.1.1. Fichiers HAL :

Les pilotes HAL sont composés du jeu de fichiers représenté dans le tableau 2.1.
Table 2.1 – Les fichiers des pilotes HAL
Fichier Description
stm32xx_hal_ppp.c Fichier principal du pilote de périphérique / module. Il inclut
les API communes à tous les périphériques STM32.
Exemple : stm32l4xx hal adc.c, stm32l4xx hal usart.c.
stm32xx_hal_ppp.h Fichier d’en-tête du fichier C du pilote principal. Il inclut les
structures de données, de descripteurs et d’énumérations
communes, les instructions et macros définies, ainsi que les
API génériques exportées. Exemple : stm32l4xx hal adc.h,
stm32l4xx hal usart.h.
stm32xx_hal_ppp_ex.c Fichier d’extension d’un pilote de périphérique / module. Il
comprend le spécifique API pour un numéro de pièce ou une
famille donnée, ainsi que les API nouvellement définies qui
écrasent les API génériques par d´défaut si le processus est
mis en œuvre de manière différente. Example: stm32l4xx
hal adc ex.c, stm32l4xx hal usart ex.c.
stm32xx_hal_ppp_ex.h Fichier d’en-tête du fichier d’extension C. Il inclut les don-
nées spécifiques et les structures d’énumération, les
instructions de définition et les macros, ainsi que les API
spécifiques au numéro de référence de périphérique exporté.
Exemple: stm32l4xx hal adc ex.h, stm32l4xx hal flash ex.h
stm32xx_hal.c Ce fichier est utilisé pour l’initialisation de HAL et contient
DBGMCU, Remap et Time Delay basé sur les API SysTick.
stm32xx_hal.h Fichier d’en-tête stm32l4xx hal.c.
28
stm32xx_hal_msp_template.c Fichier modèle à copier dans le dossier de l’application
utilisateur. Il contient l’initialisation et la désinitialisation
MSP (routine principale et rappels) du périphérique utilisé
dans l’application utilisateur.
stm32xx_hal_conf_template.h Fichier modèle permettant de personnaliser les pilotes pour
une application donnée.
stm32xx_hal_def.h Ressources HAL communes telles que des instructions de
définition commune, des énumérations, des structures et des
macros.
4.1.2. Fichiers de l’application :

Les minimums de fichiers requis pour créer une application en se basant sur HAL sont
répertoriés dans le tableau 2.2 :
Table 2.2 – Les fichiers de l’application (sous le dossier user)
Fichier Description
system_stm32xx.c Ce fichier contient SystemInit () qui est appelé au démarrage juste après
reset et avant de passer au programme principal.
Il ne configure pas l’horloge système au démarrage. Cela doit être fait
en utilisant les API HAL dans les fichiers utilisateur. Il permet de dé-
placer la table de vecteurs dans une mémoire SRAM interne.
startup_stm32xx.s Fichier spécifique à la chaîne d’outils contenant le reset handler et les

vecteurs d’exception. Ce module effectue :
— l’initialisation du pointeur de pile.
— l’initialisation du compteur ordinal.
— la définition des entrées de la table des vecteurs avec l’adresse des
exceptions ISR correspondantes.
— l’appel finalement du fonction main ().
stm32xx_flash.icf Fichier de liaison pour la chaîne d’outils EWARM permettant
principalement de définir les Régions de mémoire (adresse de début et
de fin et type d’accès : lecture seule/écriture lecture) et de définir ainsi
qu’adapter la taille de la pile et du tas aux besoins de l’application.
stm32xx_hal_msp.c Ce fichier contient l’initialisation et la désinitialisation du périphérique

utilisé dans l’application utilisateur.
stm32xx_hal_conf.h Ce fichier permet à l’utilisateur de personnaliser les pilotes HAL pour
une application spécifique.
29
stm32xx_it.c/.h Ce fichier contient les services des routines d’interruptions des
périphériques et appelle HAL IncTick () à intervalles de temps réguliers
pour incrémenter une variable locale (déclarée dans stm32l4xx hal.c)
utilisée comme base de temps HAL. Par défaut, cette fonction est
appelée
chaque 1ms dans Systick ISR.
main.c/.h Ce fichier contient la routine du programme principale, principalement :
— l’appel a` HAL Init ()
— implémentation assert failed ()
— configuration de l’horloge système
— initialisation HAL périphérique et code de l’application utilisateur.
Le package STM32Cube est fourni avec des modèles de projet prêts à l’emploi, un pour
chaque carte de développement STM32 prise en charge. Chaque projet contient les fichiers
répertoriés ci-dessus et un projet préconfiguré pour les chaînes d’outils prises en charge,
comme organisé dans la figure 2.3. Chaque modèle de projet peut être utilisé comme point de
départ pour se familiariser avec les paramètres de projet pour STM32Cube. Ses
caractéristiques sont les suivantes :
— Il contient les sources des fichiers pilotes HAL, CMSIS et BSP, qui sont les composants
minimaux pour développer un code sur une cible donnée.
— Il contient les chemins d’inclusion de tous les composants du firmware.
— Il définit le périphérique STM32 pris en charge par le biais des pilotes CMSIS et HAL.
— Il fournit des fichiers utilisateur prêts à l’emploi préconfiguré, comme défini ci-dessous:
— HAL est initialisé.
— SysTick ISR implémenté pour HAL GetTick ().
— Horloge système configurée avec la fréquence de périphérique sélectionnée.
4.1.3 Processus d’opérations HAL :
Les fonctions HAL avec traitement de données interne telles que transmission, réception,
écriture, lecture, conversion, sont généralement fournies avec trois modes de traitement de
données comme suit :
✓ Mode bloquant.
✓ Mode d’interruption.
✓ Mode DMA.
30
Figure 2.3: Structure d’un exemple modèle de l’architecture HAL
En mode bloquant, ou polling les fonctions HAL renvoient l’état du processus lorsque le
traitement des données est terminé. L’opération est considérée comme terminée lorsque la
fonction renvoie l’état HAL_OK. Dans le cas contraire, un état d’erreur est renvoyé.
Le traitement des données est effectué en interne dans une boucle. Un délai d’expiration (ex-
primé en ms) est utilisé pour empêcher la suspension du processus. La figure 2.4 décrit ce
mode de fonctionnement.
Figure 2.4: Séquence typique de traitement en mode bloquant
31
En mode d’interruption, les fonctions HAL renvoient l’état du processus après le
démarrage du traitement des données et l’activation de l’interruption appropriée. La fin de
l’opération est indiquée par un rappel déclaré comme une fonction faible. Il peut être
personnalisé par l’utilisateur pour être informé en temps réel de l’achèvement du processus.
En mode interruption, quatre fonctions sont déclarées dans les pilotes des périphériques :
— HAL_PPP_Process_IT () : pour lancer le processus.
— HAL_PPP_IRQHandler () : l’interruption globale du périphérique PPP.
—_weak_HAL_PPP_ProcessCpltCallback () : le rappel relatif à l’achèvement du
processus.
— _weak_HAL_PPP_ProcessErrorCallback () : le rappel relatif aux erreurs lors processus.
Pour utiliser un processus en mode interruption, HAL_PPP_Process_IT () est appelé dans les
fichiers utilisateur et HAL_PPP_IRQHandler dans stm32xx_it.c. Le qualificatif _weak signi-
fie que la fonction en question est surchargeable et donc l’utilisateur peut la définir à nouveau
dans l’application. Un exemple d’utilisation est illustré dans la figure 2.5.
Figure 2.5: SEQUENCE typique de traitement en mode d’interruption (non-bloquant)
En mode DMA, les fonctions HAL renvoient l’état du processus après le démarrage du
traitement des données via le DMA et l’activation de l’interruption DMA appropriée. La figure
2.6 modélise ce mode d’exécution. La fin de l’opération est indiquée par un rappel déclaré
comme une fonction surchargeable et peut être personnalisée par l’utilisateur pour être in-
formée en temps réel de l’achèvement du processus (allumer une LED par exemple).
32
L’utilisateur peut également obtenir l’état du processus via la fonction HAL_PPP_GetState ().
Pour le mode DMA, outre qu’au fonctions de rappel de fin et d’erreurs d’exécution, deux
fonctions sont déclarées dans les pilotes :
— HAL_PPP_Process_DMA () : pour lancer le processus.
— HAL_PPP_DMA_IRQHandler () : l’interruption DMA utilisée par le périphérique PPP.
Figure 2.6 : Séquence typique de traitement en mode DMA (non-bloquant)
4.2. Vue d’ensemble de la librairie Law Layer (LL) :
Les pilotes de couche inferieure sont conçus pour offrir une couche rapide, légère en termes
de taille de code et orientée vers les experts, plus proche du matériel que la couche HAL. Les
pilotes LL comportent :
✓ Un ensemble de fonctions permettant d’initialiser les principales caractéristiques du
périphérique en fonction des paramètres spécifiés dans les structures de données.
✓ Un ensemble de fonctions utilisées pour remplir les structures de données
d’initialisation avec les valeurs de reset (valeurs des registres par défaut après
système reset) de chaque champ.
✓ Fonctions permettant de désinitialiser les périphériques (les registres de périphé-
riques sont restaurés à leurs valeurs par défaut).
✓ Un ensemble de fonctions inline pour un accès registre direct.
Les pilotes LL fournissent des services matériels basés sur les fonctionnalités
disponibles des microcontrôleurs STM32. Ces services reflètent exactement les capacités
matérielles et fournissent des opérations uniques qui doivent être appelées conformément au
33
modèle de programmation décrit dans le manuel de référence (des séquences de configuration
et de traitement bien déterminés). De ce fait, les services LL n’implémentent aucun traitement
et ne nécessitent aucune ressource mémoire supplémentaire pour sauvegarder leurs états,
compteurs ou pointeurs de données intermédiaires : toutes les opérations sont effectuées en
modifiant le contenu des registres de périphériques en question. Les pilotes de couche
inférieure sont indépendants de HAL car les pilotes LL peuvent être utilisés d’une façon
autonome (sans pilotes HAL) ou en mode mixte (avec pilotes HAL) et sont construits autour
de fichiers d’en- tête et de code C (un par périphérique pris en charge) plus cinq fichiers entête
pour certaines fonctionnalités liées à System et Cortex comme présenté dans le tableau 2.3 :
Table 2.3 – Les fichiers des pilotes LL

Fichier Description
stm32xx_ll_bus.h C’est le fichier source h pour le contrôle des bus du cortex et
l’activation et la désactivation d’horloges des périphériques.
Example: LL_AHB2_GRP1_EnableClock
stm32xx_ll_ppp.h/.c stm32xx_ll_ppp.c fournit des fonctions d’initialisation de péri-
phérique telles que LL_PPP_Init (), LL_PPP_StructInit (),
LL_PPP_DeInit (). Toutes les autres API sont définies dans le
fichier stm32xx_ll_ppp.h.
stm32xx_ll_cortex.h API d’exploitation des registres du Cortex-M, y compris
Systick.
stm32xx_ll_utils.h/.c Ce fichier couvre les APIs génériques :
✓ Lecture de l’identifiant unique de l’appareil et de la
signature électronique.
✓ Gestion de la base de temps et des délais.
✓ Configuration de l’horloge système.
stm32xx_ll_system.h Operations liées au système STM32 (LL_SYSCFG_xxx,
LL_DBGMCU_xxx, LL_FLASH_xxx et LL_VREFBUF_xxx)
34
stm32_assert_template.h Fichier modèle permettant de définir la macro assert param, qui
est utilisé lorsque l’option run-time checking est activée. Ce fi-
chier est requis uniquement lorsque les pilotes LL sont utilisés
en mode autonome (sans appeler les API HAL).
Il devrait être copié dans le dossier de l’application et renommé
stm32_assert.h.
5. Analyse des besoins :

En tenant compte de toutes ces contraintes, la nouvelle plateforme de validation automatique à
concevoir doit aussi répondre aux besoins fonctionnels et non fonctionnels pour que le travail
réalisé soit conforme au cahier des charges.
5.1. Besoins fonctionnels :

La nouvelle plateforme de validation doit permettre :
- Une validation automatique de toutes les interconnexions des périphériques à valider.
- Une couverture totale des fonctionnalités.
- Le mappage automatique des scénarios pour tous les pins connectés à ces périphériques.
- La génération d’un rapport contenant les résultats des tests en temps réel.
- La flexibilité de configuration, le choix de test ou son rejet par l’ingénieur de validation .
5.2. Besoins non fonctionnels :

La nouvelle plateforme doit répondre à ces besoins non fonctionnels :
- Une architecture modulaire : L’architecture de cette solution doit être modulaire afin de faciliter
la maintenance et les mises à jour.
- Se contraindre de la durée de travail : La réalisation de ce projet ne doit pas dépasser 7mois.
- Réutilisabilité du code : Le code source de cette application peut être utilisable dans d’autres
tests de validation de l’IP en question sur un autre nouveau produit.
- La documentation du code source : Le code source doit être bien commenté afin de faciliter sa
compréhension.
35
Conclusion
Les microcontrôleurs STM32 sont largement répandus dans les systèmes embarqués, bien qu'ils
varient en fonction de leur architecture, de leur conception, de leurs performances, de leurs
domaines d'application, ils sont tous pris en charge par le même écosystème. Cet écosystème est
commun et au service de tous famille STM32. Ce chapitre était une brève introduction au micro-
contrôleur STM32 et à la plateforme logicielle intégrée.
36
Chapitre 3 :
Mise en œuvre de l’automatisation des

exemples
37
Introduction
Dans ce chapitre, nous entamons la partie conception du projet dont nous détaillons toutes les
phases de l’automatisation de l’environnement de validation. Commençant tous d’abord par
définir les exigences logicielles et matérielles et passant par la suite à la conception de
l’architecture de validation automatique sur laquelle se basent les tests et s’effectuent.
1. Exigences logicielles et matérielles

La plateforme d’automatisation des exemples STM32Cube vise à :
— Exécuter des tests automatiques et réguliers de non-régression sur les exemples de la
STM32Cube firmware à chaque fois qu’une modification dans l’environnement logiciel est
effectuée.
— Transférez facilement le logiciel de test d’une plate-forme à une autre sur la base de scripts
python génériques et d’une configuration.
1.1. Ressources matérielles :

L’objectif est de tester les exemples et les applications sans modification de code, ce qui signi-
fie que le code de test ne doit pas être ajouté à l’exemple lui-même. Pour éviter des vérifications
supplémentaires après la suppression du code de test avec les risques qu’il peut générer. La plate-
forme d’automatisation, comme décrite dans la figure 3.1, comprend :
➢ Une carte électronique d’automatisation, désormais autoboard pour le reste du rapport,
pour les mesures et la génération des événements.
➢ Un hôte PC pour :
✓ La compilation, le chargement et l’exécution des exemples et applications.
✓ L’accès aux variables d’état via STLink.
✓ La configuration et le contrôle de l’autoboard à l’aide d’une passerelle USB vers
I2C.
✓ Gestion de verdict
➢ Une cible
➢ Une passerelle USB
38
Figure 3.1 : Séquence typique de traitement en mode DMA (non-bloquant)
1.1.1. Autoboard :
L’Autoboard est une carte de validation automatique développée par STMicroelectronics
et utilisée par l’équipe de validation. L’objectif de fabrication de cette carte est l’automatisation
des tests et l’élimination de toutes forme d‘intervention manuelle sur les tests.
L’Autoboard est composée de deux cartes, une MotherBoard « MB1201 » et une DaughterBoard
« MB1202 » comme montre la figure 3.2.
Figure 3.2 : Carte de validation automatique
39
Les principales caractéristiques de la carte de validation automatique sont les suivantes :
✓ STM32F2 : Le microcontrôleur qui est responsable de la gestion des connexions de bas ni-
veau avec les 8 canaux : Connexion de n'importe quel E/S du MCU cible avec un canal,
connexion de n'importe quelle ressource de carte automatique (DAC, ADC, E/S de référence
MCU) à n'importe quel canal et configuration du ADC et du DAC.
✓ STM32F3 : Le microcontrôleur dont on utilise ses périphériques pour la validation.
✓ STM32F7 : Le microcontrôleur qui est utilisé pour la génération et la capture des signaux via
son TIMER. Il est utilisé aussi comme seconde référence « MCU référence » lors de la
validation des périphériques de communication (UART, SPI, I2C).
✓ Les matrices de multiplexage ADG : Une matrice de multiplexage admettant 12 lignes et 8
colonnes, alors 96 connections possibles permettant de connecter les Pins aux 8 canaux ou
d’interconnecter les pins du MCU cible.
✓ Deux convertisseurs analogique/numérique ADC de résolution 16 bits : Pour mesurer
automatiquement les tensions dans les pins de MCU cible.
✓ Deux convertisseurs numérique/ analogique DAC de résolution 8 bits : Pour injecter des
tensions d’une façon automatique vers des pins particuliers.
✓ Des Connecteurs BNC : Pour visualiser les signaux à partir de l'oscilloscope.
✓ Connecteur de Bus des données : Pour connecter physiquement les Entrées /Sorties du
MB1201 aux Entrées /Sorties de l’Uniboard.
✓ Deux Connecteurs JTAG : Pour le débogage des microcontrôleurs STM32F7, STM32F3 et
STM32F2.
✓ I2C Bus : est le protocole utilisé pour connecter les deux cartes, Ce protocole est basé sur un
bus de communication série, ce qui signifie qu’un seul câble est utilisé pour le transfert de
données, nommé SDA (Serial Data) et un câble pour déterminer la fréquence de la
communication, nommé SCL (Serial Clock).
✓ Connecteurs E/S : les 320 Entrées/Sorties de l’Uniboard sont connectées à travers des bus
parallèle I/O à la carte automatique de validation.
La figure 3.3 montre une vue réelle et détaillé des différents blocs de l’Autoboard .
40
Figure 3.3 : Différents blocs de l'AutoBoard
L’Autoboard permet de fournir plusieurs fonctions montrées dans la figure 3.4 tels que :
✓ Interconnecter plusieurs pins
✓ Connecter un pin à un canal de la carte
✓ Mesurer la tension sur un pin
✓ Injecter une tension sur un pin
✓ Lire une fréquence d’un signal
✓ Injecter un signal sur un pin
✓ Connecter un périphérique de communication cible
✓ Transmettre des données via un port RS232 [8].
Figure 3.4 : Fonctionnalités de la carte de validation automatique
41
1.1.2. ST-Link
Le ST-Link est un débogueur et un programmateur en circuit pour les microcontrôleurs STM8
et STM32. Les interfaces SWIM (Single-Wire Interface Module) et SWD sont utilisées pour
communiquer avec tout microcontrôleur STM8 ou STM32 situé sur une carte d'application. Ces
protocoles de débogage autorisent la lecture de tous les registres et les espaces mémoires du
microcontrôleur et permettent le diagnostic des erreurs de programmation ou de fonctionne-
ment. Une fois la lecture finie le débogueur envoi ces données par port "USB" vers
l’environnement de développement. La figure 3.5 illustre le débogueur ST-Link.
Figure 3.5 : Débogueur ST-Link
1.1.3. La passerelle USB/I2C :

La passerelle USB vers I2C, nécessaire pour la configuration de l’automatisation des
exemples, sert principalement à la traduction des commandes envoyées par l’hôte (PC / serveur) à
partir d’un port COM virtuel USB vers l’autoboard via le protocole I2C. Le choix d’un
microcontrôleur STM32 pour servir de pont PC / autoboard s’explique principalement par le fait
que la bibliothèque contenant les APIs permettant d’exploiter l’autoboard qui a atteint un bon
niveau de maturité, peut être réutilisée avec un jeu complet de fonctions Autoboard utilisant un
protocole de transfert de commandes et de données spécifique sur I2C. L’adoption de l’autre
solution, qui consiste à utiliser un convertisseur standard USB vers I2C, nécessiterait le
redéveloppement de toute cette bibliothèque. Le pont reçoit les commandes de l’hôte via UART et
les décode, le script exécuté sur l’hôte transmettra les commandes dans le format montré par la
figure 3.6 :
42
Figure 3.6 : Format de la trame transmise
AB : l’en-tête de commande.
CMD : le code de la commande et éventuellement les paramètres nécessaires à cette commande.
Le pont décode ensuite la commande, vérifie son existence et vérifie la conformité des
paramètres. Si tout le nécessaire est fourni, il envoie ensuite via I2C la commande à la carte
automatique, puis répond avec PASS ou FAIL en fonction du statut d’exécution ainsi que des
valeurs de retour en fonction de la commande.
Le tableau 3.1 liste les commandes pouvant être utilisées avec une brève description de leur
fonction.
Table 3.1 : Liste des commandes reconnues par l’autoboard
Commande Fonction
AUTOBOARD_RESET Réinitialise l’autoboard.
AUTOBOARD_RESET_ALL_CONNECTION Réinitialise les connexions de tous
les canaux de l’autoboard.
AUTOBOARD_SET_FREQUENCY Génère un signal carré avec une

fréquence spécifiée.
AUTOBOARD_GET_FREQUENCY Lit la fréquence d’un signal.
AUTOBOARD_CHECK_SIGNAL_TOGGLE Vérifie si un signal change d’état
ou non.
AUTOBOARD_GET_DUTY CYCLE Lit le rapport cyclique d’un signal
carré.
AUTOBOARD_GET_LOW_FREQUENCY Lit la fréquence d’un signal (utilisé
pour les signaux basse fréquence).
AUTOBOARD_CONNECT_PIN_TO_CHANNEL Connecte une broche à l’un des

canaux de l’autoboard.
AUTOBOARD_DISCONNECT_PIN_FROM_CHANNEL Débranche une broche de l’un des
canaux de l’autoboard.
43
AUTOBOARD_SET_VOLTAGE_TO_CHANNEL Applique une tension continue
sur une broche.
AUTOBOARD_READ_VOLTAGE_FROM_CHANNEL Lit la valeur de la tension pré-
sente sur une broche.
AUTOBOARD_SET_PULL_UP Connecte une résistance de pull-
up sur l’un des canaux.
AUTOBOARD_SET_PULL_DOWN Connecte une résistance de pull-
down sur l’un des canaux.
AUTOBOARD_PUSH_BUTTON Emule un appui de bouton sur

une broche sélectionnée avec la
polarité sélectionnée.
AUTOBOARD_HYPERTERMINAL_WRITE Transmet un message UART
vers l’UART de la carte cible
(destiné à l’automatisation des
exemples UART).
AUTOBOARD_HYPERTERMINAL_READ Reçoit un message UART à

partir de l’UART de la carte
cible (destiné à l’automatisation
des exemples UART).
AUTOBOARD_HYPERTERMINAL_SEND_READ Transmet puis reçoit un message

UART dans les broches UART
cibles (destiné à
l’automatisation des exemples
UART).
HALT_AND_CATCH_FIRE Réinitialise le pont.
1.2. Ressources logicielles :
Le logiciel d’automatisation est construit autour de plusieurs composants logiciels qui

s’exécutent sur les différents matériels utilisés dans la plateforme automatique :
✓ Exemples du STM32Cube firmware : les projets ”.ewp” qui seront compilés, chargés
en mémoire et exécutés sur la carte cible. Ces exemples sont situés sous les projets
Firmware (Le dossier sous lequel se trouvent les exemples).
✓ API de la passerelle USB / I2C : s’exécutant sur l’hôte et basé sur un script python,
communique avec la carte nucléo utilisée comme passerelle pour contrôler l’autoboard.
44
Cette API utilise le port COM virtuel pour communiquer avec la carte nucléo (toutes
carte STM32 Nucléo ayant une instance USART liée au VCP servira comme passerelle).
✓ L’API de l’automatisation : Le logiciel intégré dans la passerelle USB / I2C utilisé
pour configurer et contrôler l’autoboard pour établir des connexions d’E / S, effectuer
des mesures, etc.
Autoboard_Reset() : Cette API réinitialise toutes les MCUs dans l’Autoboard. La figure
3.7 décrit le mécanisme de fonctionnement de cette API [5].
Figure 3.7 : Schéma de fonctionnement de l'API Autoboard_Reset ()
• Connect_PinToChannel (Pinx, Board_ChannelY) : Cette API permet de faire une

connexion entre le pin d'adresse "Pinx" de l’Uniboard à une chaine de l’Autoboard
"Board_channelY". L’établissement de cette connexion physique permettra d’agir sur les
pins du périphérique sous test depuis l’Autoboard, soit en leurs fournissant un signal
comme entrée ou récupérer leurs signaux pour réaliser un traitement par l’Autoboard. La
figure 3.8 illustre le mécanisme de fonctionnement de cette API [5].
45
Figure 3.8 : Schéma de fonctionnement de l'API Connect Pin to Channel
✓ Moteur d’automatisation : sur la base des scripts globaux d’hôte qui servent à :
— Lancer la compilation des exemples et charger les exemples automatisés sur les cartes
cibles en fonction du contenu de jenkins_config.xml.
— Récupérer et lancer le fichier de test Python associé.
— Gérer le verdict du test.
✓ test.py : c’est le script de validation de l’exemple, il est dédié à chaque scénario
d’exemple automatique. Ce script python sera exécuté sur le PC hôte et sera lancé
après l’exécution de l’exemple sur la carte Cible.
2. Description de la plateforme de test :

L’hôte compile un ensemble de projets répertoriés dans un fichier XML (fourni en entrée),
puis extrait le script de test correspondant et l’exécute. La figure 3.9 représente une description
des différents fichiers et dossiers utilisés.
L’hôte importe uniquement les scripts de test situés dans la base de données du générateur
de projets. Cette base de données est disponible dans tous les dépôts, en effet le logiciel de
gestion de versions utilisé, c’est Git, et un dépôt n’est qu’une copie du projet. Chaque
développeur doit cloner un dépôt du projet sur lequel il travaille pour récupérer tout
l’historique et tous les codes source.
46
Figure 3.9 : Architecture globale [4]
Comme il s’agit d’un travail en équipe, les responsables des projets sont chargés de lire,
approuver ou rejeter les modifications d’un code source à travers une interface web dédié,
Gerrit, Il s’utilise avec Git et qui s’occupe de poster ces changements de code. On peut
l’assimiler à une couche sous git servant d’un pont qui ne laisse passer qu’un code sûr afin de
garantir la qualité et la maintenance du code. Pour ces raisons, il faut toujours être à jour avec
les dernières modifications et suivre les méthodes et règles de travail que nécessite git.
Le dépôt en question est composé des fichiers / répertoires comme illustré dans la figure
3.10 dont le tableau 3.3 décrit les scripts python utilisés.
47
Figure 3.10 : Architecture d'un dépôt d'un projet STM32 [4]
48
Table 3.3 – Description des scripts d’automatisation
Script/fichier Description
automatic_check.py C’est le point d’entrée de l’hôte : Pour exécuter
l’automatisation des exemples, ce fichier doit être appelé
via l’interface de ligne de commande.
validation.py Le module principal qui analyse le fichier XML qui
répertorie les projets à compiler, appelle les testeurs
associés, puis attend un verdict.
Test_runner_auto_ex.py Testeur automatique : ce module charge le fichier de
script de test, l’exécute, attend un verdict et met à jour le
résultat du test.
stlink.py Ce module fournit un wrapper à STLink-CLI. Il
comprend les fonctions nécessaires au contrôle de la cible
(connexion, reset, chargement du binaire dans la mémoire
flash, lecture / écriture de données)
dumper.py Ce module fournit des outils plus avancés qui s’ajoutent a`
stlink.py (dump/écriture des buffers)
embVar.py Ce module fournit une interface pour travailler sur les
variables embarquées en utilisant stlink.
Il permet de lire / écrire des variables typés (signés, non
signés, char) dans les scripts de test.
Autoboard.py Ce module est l’API qui servira à contrôler l’autoboboard
(injection des tensions, lecture de fréquence)
genericTest.py Ce module utilise la base donnée du générateur de projet
pour remplacer les mots-clés.
ide.py Ce module constitue un wrapper à toutes les fonctions
nécessaires à la compilation / nettoyage du projet et à la
modification des options de construction (build options).
Project.py Ce module fait partie du générateur de projet. Il analyse
le fichier XML du projet et offre des fonctions utiles
(remplacement de mots-clés...).
Target.py Ce module fait partie du générateur de projet. Il analyse
le fichier XML cible et offre des fonctions utiles
(remplacement des mots-clés)
test.py Il s’agit du script de test qui sera importé par le testeur
test runer auto ex.py et exécuté, puis renvoie un verdict
PASS ou FAIL.
49
gen_jenkins_config_pg.sh Ce Shell génère un fichier XML qui répertorie tous les
projets à compiler et à tester.
Jenkins_config_xx.xml Ce fichier illustré dans l’annexe 2 est la sortie du script
Shell gen_jenkins_config_pg.sh. Il sera passé comme
argument à automatic_check.py.
Autoboard_config.xml Ce fichier illustré dans l’annexe 3 contient toutes les
commandes autoboard avec leurs identifiants, nombre de
paramètres et leur type.
Bench.xml Ce fichier illustré dans l’annexe 3 répertorie le nom des
cartes (DUT) et leurs numéros de série, qui seront utilisés
lors d’un accès via ST-Link.
3. Catégories d’automatisation :
Suivant la complexité de l’automatisation, les exemples et les applications du STM32Cube sont
divisés en 3 catégories :
3.1. Automatisation de la catégorie 1 :

Les exemples et les applications de ce groupe sont les plus simples à automatiser. En
général, à la fin de l’exécution de ces exemples, une led s’allumera indiquant le verdict de
l’exemple. Pour faciliter l’automatisation de l’exemple, nous ajouterons une variable en plus
du statut indiqué par les voyants et contrôlerons le statut de cette variable lors de
l’automatisation du test.
L’autoboard n’entre pas en jeu dans ce cas : le verdict (PASS ou FAIL) peut être simplement
déduits avec lecture de variable via ST-LINK.
La procédure du développement d’un nouveau test est la suivante :
1 Identification des noms / types des variables globales à vérifier.
2 Reset de la carte avant le lancement du test.
3 Pause jusqu’à la fin de l’exécution [while (1)] et lecture des variables nécessaires pour le test.
4 Si le contenu de la variable = prévu, nous retournons PASS, sinon c’est un FAIL.
L’organigramme de la figure 3.11 décrit la chaîne d’exécution d’un parmi les tests de cette
catégorie, celui de l’exemple CRC UserDefinedPolynomial, cet exemple calcule le code crc et
le stocke dans une variable globale uwCRCValue.
Il suffit donc de vérifier le contenu de cette variable pour obtenir un résultat de test.
50
Figure 3.11 : Exemple de test d’exemples de la catégorie 1

Un accès direct uniquement via ST-Link peut entièrement automatiser certains exemples,
mais il a ses limites : il ne peut pas automatiser ceux qui requièrent des interactions de
l’utilisateur (Appuyer sur un bouton-poussoir, injecter un signal PWM avec 30% de rapport
cyclique, lire une valeur ADC, injecter une tension...).
Autoboard est utilisé ici : elle peut reproduire ces interactions, effectuer toutes les configu-
ration / commandes nécessaires requises par l’exemple, puis faire rapport à l’hôte, qui gère
ensuite le verdict PASS / FAIL. Les exemples de cette catégorie nécessitent un scénario
d’automatisation simple via l’autoboard.
Par exemple pour l’exemple ADC_SingleConversion_TriggerSW_IT l’utilisateur doit
injecter une tension dans une broche, puis lire le contenu de la variable ” uhADCxConverted-
Data_Voltage_mVolt ”. L’idée est donc d’exécuter un nombre X de lectures et de détecter si
elles sont dans les plages acceptables. Si oui, rendre un verdict PASS.
51
Pour développer un test pour l’exemple mentionné ci-dessus, nous suivons cette approche,
nous :
✓ Identifions le nom / type des variables globales à vérifier.
✓ Initialisons l’autoboard.
✓ Injectons une tension dans la broche d’entrée de l’ADC.
✓ Lisons le contenu de la variable (adcVoltage) et calculez l’erreur (en boucle).
✓ Dès que l’erreur sort de la plage de tolérance, nous retournons FAIL.
✓ Si nous sommes sortis de la boucle, nous retournons PASS.
La broche à utiliser peut varier d’une cible à l’autre, nous utilisons donc le module
genericTest.py afin de convertir le nom générique (ADC PIN) figurant dans le config.xml
montré dans l’annexe 4 du projet (fichier de base pour la génération des exemples), en
fonction de la cible, en l’identifiant de la broche en question.
Le diagramme de la figure 3.12 décrit comment l’exemple
ADC_SingleConversion_TriggerSW_IT est automatisé.

52
Les tests automatiques qui entrent dans cette catégorie sont plus complexes à développer car
ils nécessitent des exigences supplémentaires. Dans cette catégorie, nous pouvons lister :
✓ Exemples nécessitant de commenter et de décommenter un commutateur de compilation (#define

MASTER dans les exemples COM maître / esclave)
✓ Exemples nécessitant le développement d’un code miroir (deux cartes COM)
✓ Exemples nécessitant davantage de connaissances python approfondies (installation de modules
de reconnaissance d’images pour tester des exemples DMA2D)
A titre d’exemple, UART_TwoBoards _ComDMA est un exemple qui nécessite deux cartes
STM32 pour le tester, mais l’autoboard ne supporte d’une seule cible (DUT) d’où vient l’i dée
d’utiliser le microcontrôleur STM32F7 de l’autoboard comme deuxième partie de la communica-
tion.
Dans cet exemple, l’utilisateur doit appuyer sur le bouton utilisateur de la carte maître pour
lancer la communication, le scénario d’exécution du point du vue la carte esclave est le suivant :
✓ Le maître (F7) envoie un message à l’esclave.
✓ L’esclave (DUT) renvoie le message.
✓ Le maître compare les messages envoyés et reçus.
Pour d´développer un test pour l’exemple mentionné ci-dessus, nous suivons cette approche, nous
:
✓ Identifions le nom / type des variables globales à vérifier.
✓ Initialisons la carte automatique.
✓ Simulons un appuie sur un bouton avec l’autoboard.
✓ Lisons le message reçu de la cible (maître).
✓ Renvoyons le message.
✓ Lisons le résultat de la comparaison des messages : s’ils correspondent, nous retournons un
PASS, sinon nous renvoyons un FAIL.
La figure 3.13 décrit comment un l’exemple UART_TwoBoards_ComDMA (du point du vue
esclave) est automatisé :
53
4. Mise en place d’une plateforme de validation basée à l’Autoboard et

plateforme jenkins :
Nous avons mis en place une plateforme de validation automatique, qui facilite le process de
validation et le rendre plus efficace. Cette plateforme se base sur le principe d’intégration continue ce
qui la rendre centralisée. La figure 3.14 montre le setup utilisé pour l’automatisation.
54
Figure 3.14 : Setup utilisé pour l’automatisation
Etape 1 : Automatisation du test

C’est une phase de portage qui consiste à créer un environnement de validation
automatique pour une IP donnée à partir des autres baseslines, des tests manuels...
Dans cette phase, on spécifie si les scénarios de test pour cette IP nécessitent l’intervention
de l’Autoboard ou non. Le cycle du processus de validation automatique de l’IP commence
par la réinitialisation de l’Autoboard et la restauration des donnés sauvegardées dans la
mémoire backup de l’Autobaord pour assurer la continuité de la validation. Ensuite, après
une vérification de l’état de système une décision sera prise pour exécuter les tests
fonctionnels automatisés. Enfin, le cycle de processus se termine par la génération d’un
rapport contenant les résultats de chaque test.
La figure 3.15 montre le mécanisme général pour exécuter tous les tests automatisés.
Etape 2 : Review
Durant cette étape, une vérification du code se fait par des spécialistes afin de valider si le
code respect les normes et fonctionne convenablement, la figure 3.16 montre la version des
codes dans Gerrit avant la vérification.
Etape 3 : Push
Une fois le code est prouvé, sera transféré vers le serveur principale ce qui est montré par la
figure 3.17.
Etape 4 : Configuration et Exécution de Job

Le serveur d’intégration triggé par plusieurs sources soit de façon directe par l’ingénieur à
travers Jenkins, soit de façon indirecte par détection automatique de changement.
55
En générale, nous utilisons la façon directe afin d’optimiser nos ressources matérielles. Une
fois le serveur triggé, il exécute le job, ceci est montré dans la figure 3.18.
Figure 3.15 : Cycle de processus de validation automatique
56
Figure 3.16 : Version des codes dans Gerrit avant la vérification
Figure 3.17 : Transférer vers le serveur principal
Figure 3.18 : Configuration et Exécution de Job
57
Etape 5 : Rapport et notification
Après l’exécution de job ; compilation, exécution, test, Jenkins rend un rapport qui
détaille l’état des tests exécutes en spécifiant les tests pass /fail/skipped où il y a des erreurs
des compilations.
4.1.L’outil Jenkins :
Jenkins est un outil logiciel d’intégration continu montré dans la figure 3.19. Il s’agit
d’un logiciel open source, développé à l’aide du langage de programmation Java. Il permet
de tester et de rapporter les changements effectués sur une large base de code en temps réel.
Ce logiciel permet aux développeurs de détecter et résoudre les problèmes dans une base de
code rapidement. Ainsi les tests de nouveaux builds peuvent être automatisés, ce qui permet
d’intégrer plus facilement des changements à un projet, de façon continue. L’objectif de
Jenkins est l’accélération de développement de logiciels par le biais de l’automatisation. Il
permet l’intégration de toutes les étapes du cycle de développement.
Figure 3.19 : Outil logiciel d’intégration Jenkins
4.2.Génération du rapport de validation

Pour donner une information détaillée sur les résultats de validation, la solution logicielle
proposée doit enfin de test, générer un rapport complet de validation. Ce rapport doit être clair,
lisible, et très proche de l’intuition humaine afin d’épargner l’ingénieur de validation le temps
58
de compréhension de la signification des titres et des symboles. Le rapport de validation est
présenté sous forme d’un fichier texte et il permet d’aider énormément dans l’investigation en cas
de détection d’un disfonctionnement, car il décrit exactement l’étape de validation ou on a des
problèmes. En plus de l’affichage des zones de disfonctionnement, le rapport affiche les valeurs
des mesures ainsi que les valeurs souhaitées (valeurs théoriques conformément à la spécification
du produit).
La figure 3.20 illustre un exemple d’affichage en cas de parcours de plusieurs REMAP.
Figure 3.20 : Affichage en cas de validation de plusieurs REMAP
A la fin des tests, un résumé est affiché :

_ Pour indiquer les tests ignorés.
_ Pour indiquer les résultats de validation des tests des IP
La figure 3.21 représente un résumé du rapport de validation de 93 exemples dont 92 exemples

ont passé sans erreurs alors qu’on a un exemple qui a échoué.
59
Figure 3.21 : Résumé de validation
5. Rentabilité de l’Automatisation
La rentabilité de ce projet d’automatisation peut être perçue sur cinq axes :
✓ Réduction des charges : une fois mis en place, les tests automatiques peuvent être
lancés sans aucune assistance humaine. Ainsi nous gagnerons le temps nécessaire pour
la réexécution manuelle des tests. Cette réduction de charges peut être traduite par un
gain considérable dans le budget-projet.
✓ Couverture des fonctionnalités de nos périphériques.
✓ Minimisation du temps d’investigation grâce à la génération d’un rapport de validation
détaillé.
Le tableau suivant renferme le temps de validation avant et après l’automatisation :
Tableau 4.1 : Temps de validation avant et après l’automatisation
IDE utilisé Validation Validation Nombre total

Manuelle Automatique de tests
IAR 15 jours 3h 134
Keil 12 jours 2h 95
Cubeide 12 jours 2h 95
Total 39 jours 7h 324
✓ Réutilisabilité des tests : les tests automatiques peuvent être paramétrés et modifiés
selon les données du produit et cette plateforme de test peut être réutilisée lors de la
validation de tout produit contenant le même périphérique.
60
Conclusion :
Dans ce chapitre, nous avons expliqué le processus de l’automatisation qui ont permis de
remplacer les tâches manuelles par des APIs de l’Autoboard, ajouter des nouveaux APIs à
l’Autoboard, assurer la sauvegarde de toutes les données même après une réinitialisation et
finalement générer un rapport détaillé.
61
Conclusion générale
Le support technique, offert par les entreprises exerçant dans le domaine des semi-
conducteurs, représente un axe important sur lequel s’appuie les différents acteurs de cette
industrie pour améliorer leur chiffre d’affaires.
En effet, fournir des solutions software parallèlement au matériel proposé, constitue une assis-
tance inévitable à la faveur des développeurs des systèmes électroniques. Pour garantir une
simultanéité entre le développement matériel et logiciel, STMicroelectronics a choisi
d’accélérer le développement logiciel par l’automatisation des tâches répétitives et
gourmandes en termes de ressources temporelle et matérielle.
Dans cette perspective, ce projet consiste à automatiser la validation des exemples des
Firmware d’un microcontrôleur spécifique.
Afin d’accomplir ce projet, nous avons exploité les outils matériels et logiciels développé par
les équipes de la division Micro Controller Devision (MCD) de ST.
En premier lieu, nous avons mis en place les différentes plateformes qu’exige ce projet, en
second lieu, nous nous sommes documentés sur les processus et les stratégies de travail, puis
nous avons automatisé la validation de ces exemples et détailler toutes les phases
d’automatisation des cotés matérielle et logicielle. Comme perspective, il reste une marge
d’amélioration tels que la configuration automatique et intelligente de la plateforme de test au
lieu de le faire manuellement à l’instant actuel de même les API de notre Autoboard ne
supporte pas tous les exemples ce qui rend l’automatisation de la validation est limitée donc
on a un problème d’automatisation de quelques IP.
62
Bibliographie
[1] Mastering STM32 A step-by-step guide to the most complete ARM Cortex-M platform, using a free and
powerful development environment based on Eclipse and GCC. Leanpub. [Consulté le10 /09/2021].
[2] https://www.st.com/content/ccc/resource/corporate/company/company_presentation/8d/fc
/ba/0b/41/0d/47/12/company_presentation.pdf/files/company_presentation.pdf/_jcr_content/t
ranslations/en.company_presentation.pdf. [Consulté le12 /09/2021].
[3] STMicroelectronics stm32-32-bit-arm-cortex-mcus. https://www.st.com/en/microcontrollers-
microprocessors/stm32-32-bit-arm-cortex- mcus.html. [Consulté le /14/2021].
[4] Team, T. F. (2018-2019b). Internal documentation. [Consulté le 16/09/2021].
[5] Autoboard_API, Document interne STMicroelectronics [Consulté le16 /09/2021].
[6] ARM: Cortex-M33 Spécifications Disponible sur : https://developer.arm.com/ip
products/processors/cortex-m/cortex-m33 [Consulté le 20/09/2021].
63
Annexe 1
Figure 3.22 : Arborescence du Firmware
64
Annexe 2
Figure 3.23 : Structure du fichier Jenkins_config_fw.xml
65
Annexe 3
Figure 3.24 : Autoboard_config.xml de la carte STM32
Figure 3.25 : Bench.xml de la carte STM32
66
Annexe4
Figure 3.26 : Config.xml d’un exemple ADC
67
République Tunisienne Cycle de Formation d’Ingénieurs dans la Discipline
Ministère de l’Enseignement Supérieur Génie Electrique
et de la Recherche Scientifique
Université de Sfax ST-EN07/00
École Nationale d’Ingénieurs de Sfax Projet de Fin d’Etudes
N° d’ordre: 2021/DGE-019
Automatisation de la Validation des Exemples de la STM32Cube Firmware
Islam MOUSSI
‫( ألجهزة‬Firmware) ‫ إن مشروع تخرجي يقدم طريقة جديدة إلثبات األداء الجيد لألمثلة والتطبيقات‬:‫الخالصة‬
‫ من أجل‬،‫وأخيرا‬. ‫ يدويا‬Firmware STM32 ‫ ثم أكدنا صحة عمل أمثلة‬،‫ بدأنا بتنفيذ بيئة العمل‬STM32 ‫التحكم‬
‫ قمنا بأتمتة جميع اختبارات أمثلة المشاريع باستخدام منصة وضعتها‬،‫اإلسراع في التحقق من صحة أمثلة األجهزة‬
STMicroelectronics ‫شركة‬
Résumé : Mon projet de fin d’études présente une nouvelle façon de valider le bon
fonctionnement des exemples et des applications (Firmware) des périphériques du
microcontrôleur STM32.
Nous avons commencé par la mise en place de l’environnement de travail, puis on a
validé le bon fonctionnement des exemples STM32 Firmware manuellement.
Enfin, afin d’accélérer la validation des exemples de périphériques, nous avons
automatisé tous les tests des exemples de projet à l’aide d’une plateforme développé par
STMicroelectronics.
Abstract: My graduation project presents a new way to develop examples and

applications (Firmware), and to validate the well-functioning of the STM32
microcontroller’s peripherals.
We started by setting up the working environment, then we validated the correct
operation of the STM32 Firmware examples manually.
Finally, in order to speed up the validation of device examples, we have automated all
tests of project examples using a platform developed by STMicroelectronics.
Mots clés : STM32, Automatisation, git, jenkins, Firmware, validation.
Key-words: STM32, Automation, git, jenkins, Firmware, validation
Adresse : Route Soukra Km 3.5 B.P 1173 - 3038 Sfax-TUNISIE - ‫ تونس‬- ‫ صفاقس‬3038 -1173 ‫ ب‬. ‫ ص‬3.5 ‫ طريق سكرة كلم‬:‫ع نوان‬
Téléphone : 74 274088 Fax : 74275595 74 275 595 :‫ الف اكس‬74 274 088 :‫الهاتف‬
Site web : www.enis.rnu.tn www.enis.rnu.tn :‫موقع الواب‬
« l’ENIS enseigne l’Innovation »

Memoire: Automatisation de La Validation Des Exemples de La STM32Cube Firmware

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Memoire: Automatisation de La Validation Des Exemples de La STM32Cube Firmware

Transféré par

Droits d'auteur :

Formats disponibles

République Tunisienne Cycle de Formation d’Ingénieurs dans

Ministère de l’Enseignement Supérieur la Discipline Génie Electrique

L’Ecole Nationale d’Ingénieurs de Sfax

Du Diplôme National d’Ingénieur en Génie Electrique

Automatisation de la Validation des Exemples de la STM32Cube

Soutenu le 02 Octobre 2021, devant la commission d’examen :

M. Chokri REKIK Président

M. Hafedh ABID Rapporteur

M. Hatem TRABELSI Encadrant Académique

M. Chokri GAMMOUDI Encadrant Industriel

M. Rabie ABDAOUI Co-encadrant

J’adresse tout d’abord mes remerciements les plus sincères à la société

Je voudrais également exprimer ma gratitude et mon sincère respect à mes superviseurs

Je suis également extrêmement reconnaissante à M. Hatem TRABELSI, mon superviseur

Je voudrais également remercier M. Rabie ABDAOUI, M. Mohamed Ali Hachicha et

Dernier et le plus important, je voudrais exprimer mon amour et ma profonde gratitude à

Remerciements ...................................................................................................................... iii

Liste des acronymes....................................................................................................................x

Introduction Générale .................................................................................................................1

Chapitre 1 : Présentation du cadre générale du projet......................................................3

1.1. STMicroelectronics Tunis ............................................................................................7

3.1. Contexte du projet ..................................................................................................... 11

4.1 Objectifs du projet ..................................................................................................... 17

Chapitre 2 :Etude préalable sur les microcontrôleurs et la plateforme logicielle intégré 19

2. Le microcontrôleur STM32 .............................................................................................. 21

3.1. Le périphérique ou IP……………………………………………………………….25

4.1 Vue d’ensemble de la librairie Hardware Abstraction Layer (HAL) ......................... 27

5.1. Besoins fonctionnels.................................................................................................. 35

1. Exigences logicielles et matérielles .................................................................................. 38

3.1. Ressources matérielles .............................................................................................. 38

3. Catégories d’automatisation .............................................................................................. 50

3.1. Automatisation de la catégorie 1 ............................................................................... 50

4.1. L’outil Jenkins ........................................................................................................... 58

Table 2.1 : Les fichiers des pilotes HAL ........................................................................27

Présentation du cadre générale du projet

1. Présentation de l’entreprise d’accueil :

Figure 1.1: logo de STMicroelectronics

Maintenant, STMicroelectronics est un leader mondial qui développe, fabrique et

Figure 1.2: Gamme de produits de STMicroelectronics [2]

Figure 1.3: Marchés ciblés par ST [2]

1.1. STMicroelectronics Tunis :

Figure 1.4: Site tunisien de STMicroelectronics

Les principales activités attribuées du site de Tunis sont :

1.2. L’équipe Test Framework :

Figure 1.6: DIE interne d’un MCU STM32F103 [1]

Figure 1.7: Le portefeuille STM32 [3]

✓ Les microcontrôleurs hauts performances sont les microcontrôleurs STM32 dédiés

3.1. Contexte du projet :

3.3. Etude de L’existant :

3.3.1. Description de l’existant :

Figure 1.9: Vérification FPGA

✓ Le développement des scénarios de test : Consiste à développer des nouveaux

3.3.2 Critique de l’existant :

4.1 Objectifs du projet :

4.2 Méthodologie du travail :

1. Généralité sur les microcontrôleurs :

✓ Un oscillateur pour le cadencement. Il peut être réalisé avec un quartz, un circuit RC ou

La matrice de bus convertit l’interface d’interconnexion de bus Harvard interne du

— S0 : I-CODE Cible principalement la mémoire programme : Ce bus est utilisé par le

2.2. Architecture système de STM32 :

Les microcontrôleurs STM32 de STMicroelectronics fournissent une vaste gamme de

3. Généralités sur les périphériques

3.1. Les registres :