par Lotta Frimanson et Anders Lundgren (IAR Systems)

28 / L’EMBARQUÉ / N°1
Application  Développement
Lotta Frimanson
et de Anders
Lundgren,
responsables
produit chez
IAR Systems
Visualiser la consommation
d’un microcontrôleur via
un environnement de débogage
Comment détecter les fuites d’énergie et comment optimiser le logiciel applicatif
pour minimiser la consommation d’énergie dans un système embarqué ? La technologie
du débogage énergétique (power debugging) est une solution pour y parvenir.
IAR Systems, présente ici des cas concrets où cette approche s’avère très utile.
L
a notion de débogage éner-
gétique fournit aux déve-
loppeurs l’information
nécessaire pour déterminer
comment l’implémentation d’un
logiciel embarqué affecte la consom-
mation énergétique d’un système à
base de microcontrôleur (MCU). En
corrélant code source et consomma-
tion, il est possible de tester ce logi-
ciel embarqué et de l’ajuster pour
l’optimiser au plan énergétique.
Aujourd’hui, la durée de vie de la
batterie (ou d’une pile) est un facteur
extrêmement important pour les sys-
tèmes embarqués dans presque tous
les segments du marché : le médical,
le grand public, la domotique et bien
d’autres. Traditionnellement, la
consommation d’énergie relevait des
concepteurs de matériel et ils sem-
blaient les seuls en mesure d’influer
sur sa valeur. Pourtant dans un sys-
tème en fonctionnement, cette
consommation dépend autant du
matériel que de la manière de l’uti-
liser ; or cette manière découle direc-
tement du logiciel embarqué dans le
système.
La technologie de débogage énergé-
tique, mise au point par IAR Systems,
permet de visualiser la consomma-
tion d’un système via les outils de
développement de logiciel embar-
qué. Cela revient à mettre entre les
mains des développeurs un outil les
aidant à minimiser la consommation
en agissant au cœur du logiciel
embarqué : c’est ce que nous appe-
lons le débogage énergétique.
Le débogueur IAR C-SPY relève les
données de consommation énergé-
tique, aussi bien statistiquement que
dynamiquement, et permet de les
afficher sous différentes formes. Il
fournit également les moyens d’ef-
fectuer un profilage et un débogage
énergétique de l’application.
Comment fonctionne
le débogage énergétique ?
Cette technologie repose sur l’acqui-
sition d’échantillons de valeurs de la
puissance consommée puis sur la
corrélation de chaque échantillon
avec la séquence correspondante
d’instructions du programme, donc
avec le code source. L’une des diffi-
cultés consiste à obtenir un échantil-
lonnage de haute précision. Dans
l’idéal, il faudrait mesurer la consom-
mation à la fréquence d’horloge du
système ; cependant les capacités
intrinsèques au système réduisent la
fiabilité de telles mesures. Autrement
dit, la consommation mesurée peut
être « polluée » par rapport à la
consommation effective du CPU et
des périphériques.
En fait dans la pratique, ce problème
n’en est pas un. En effet, du point de
vue du concepteur, il est beaucoup
plus intéressant de corréler la puis-
sance consommée avec le code
source et divers événements interve-
nant dans l’exécution du programme
qu’avec les instructions proprement
dites. La résolution nécessaire est
donc bien plus faible qu’un échan-
tillon par instruction.
Au sein du circuit, la consommation
est mesurée grâce à une sonde, IAR
I-scope dans notre cas, qui évalue la
différence de tension aux bornes
d’une petite résistance mise en série
entre la source d’alimentation et le
dispositif. I-scope doit être utilisée en
association avec la sonde de débo-
gage IAR I-jet (figure 1). La chute de
tension est mesurée par un amplifi-
cateur différentiel puis est échantil-
lonnée grâce à un convertisseur ana-
logique-numérique. Cette technique
autorise la mesure du courant en tout
point de la carte.
La clé d’un débogage énergétique
précis est la justesse de la corrélation
entre la trace d’instruction et les
mesures de puissance consommée.
La meilleure corrélation est obtenue
si une trace d’instruction complète
est disponible ; ce qui est le cas avec
le support ETM (Embedded Trace
Macrocell) des MCU ARM. Le pro-
blème est que deux conditions
doivent être remplies : l’usage d’une
sonde de débogage spéciale et la
prise en charge d’ETM au sein du
dispositif.
Une technique moins précise mais
donnant encore une bonne corréla-
tion consiste à utiliser la fonction
d’échantillonnage du compteur de
programme (PC) qui est disponible
dans les cœurs ARM Cortex-M3/M4
(figure 2). Le module DWT implé-
mente l’échantillonneur et relève le
Régulateur
de tension MCU
Carte sous test
Résistance 1 Ω
(pour 100 mA max.)
I+I-
Jtag
VDD
1 MESURE DE CONSOMMATION
La chute de tension est ici mesurée par
un amplificateur différentiel puis échantillonnée
grâce à un convertisseur A/N autorisant
la mesure du courant en tout point.
AUTEURS

L’EMBARQUÉ / N°1 / 29
Développement  Application
PC régulièrement, jusqu’à 50 000 fois
par seconde. Pour chaque échantillon
acquis, un paquet ITM (Instrumenta-
tion Embedded Macrocell) est stocké.
L’ITM a pour rôle de formater les évé-
nements issus du DWT. Il les range et
les horodate. La sonde de débogage
échantillonne la puissance consom-
mée par le dispositif via un convertis-
seur analogique-numérique. Par le
marquage temporel des données
énergétiques et des valeurs du PC, il
est alors possible au débogueur de
présenter la consommation sur le
même axe des temps que les courbes
chronologiques d’arrivée des inter-
ruptions, ou d’évolution des variables,
et de corréler les données de consom-
mation avec le code source.
Afficher les valeurs
du débogage énergétique
Comme indiqué précédemment, le
débogage énergétique implique
l’échantillonnage de la puissance
consommée et la corrélation de
chaque échantillon avec le code
source. Dans l’outil IAR Embedded
Workbench, les mesures de puis-
sance peuvent être affichées sous
différents formats. Ainsi la fenêtre
« Power Log » donne le graphique
complet des mesures de consomma-
tion collectées. Elle permet de repé-
rer les pics de consommation et,
puisque les mesures sont corrélées
avec le code exécuté, de retrouver le
code correspondant en double-cli-
quant sur une valeur d’énergie. La
précision dépendra de la fréquence
d’échantillonnage de la mesure de
puissance, mais elle suffit le plus sou-
vent à retrouver la séquence de code
responsable du pic.
Une autre façon d’étudier les échan-
tillons de consommation peut se
faire via la fenêtre « Timeline ». Dans
cette fenêtre chronologique, les
mesures de puissance sont affichées
sur l’axe des temps avec les interrup-
tions éventuelles et un maximum de
quatre variables d’application à choi-
sir (figure 3).
Dans les systèmes embarqués, les
périphériques sont responsables
d’une grande partie de la consom-
mation de puissance et, qu’ils soient
ou non intégrés dans le microcontrô-
leur, leur utilisation est contrôlée par
logiciel. La fenêtre « Timeline » est
donc extrêmement utile pour corré-
ler la consommation avec les appels
de fonctions et, en choisissant des
variables dépendant de l’état de tel
ou tel périphérique, avec des activi-
tés pouvant faire grimper la consom-
mation. L’objectif est évidemment de
voir si le code peut être optimisé sur
le plan énergétique.
De plus, la fenêtre « Timeline » étant
corrélée avec la fenêtre « Power Log »
et celle du code source, un simple
double-clic sépare ce dernier des
valeurs présentées sur l’axe des temps.
Vers un profilage énergétique
Dans la pratique, et notamment dans
un système structuré en tâches, il est
probablement plus intéressant de
suivre comment la consommation
évolue avec chaque fonction plutôt
qu’avec chaque instruction. Pour un
stimulus donné, le profileur fonction-
nel aide à identifier les fonctions
dont l’exécution est la plus longue.
Il fait ainsi apparaître clairement les
zones de l’application qu’il faudrait
optimiser sur le plan énergétique.
Avec un processeur Cortex-M3 par
exemple, le débogueur peut utiliser
la possibilité d’échantillonnage du
compteur de programme dans le
module DWT. Grâce à cette fonc-
tionnalité, le débogueur peut fournir
une analyse de performance statis-
tique. Le profileur retrouve les fonc-
tions corrélées avec la valeur du PC
et crée une base de données interne
répertoriant le nombre de fois où
chacune d’elles s’exécute, pour
générer une analyse de performance
de fonctions. Le débogueur affiche
cette information pour chaque fonc-
tion d’une application pendant l’exé-
cution de celle-ci.
Pour le profilage énergétique, on
combine le profilage de fonction
avec les échantillons de mesure de
consommation pour obtenir la
consommation de chaque fonction,
et l’afficher dans la fenêtre « Function
Profiler » (figure 4 page suivante).
Cette fenêtre « Function Profiler »
présente pour chaque fonction le
nombre de fois où une mesure a été
relevée ainsi que les valeurs
moyennes, maximales et minimales.
Une fois de plus, on peut aisément
repérer les pics de consommation et
les comportements énergétiques
anormaux au sein du système embar-
qué analysé. En effet, un système
peut sembler fonctionner parfaite-
ment et satisfaire entièrement les
tests effectués, et néanmoins la puis-
sance consommée peut y être nette-
ment plus élevée que nécessaire ; et
maintenant nous avons un moyen de
le détecter.
En général, ce travail d’optimisation
de la consommation est très proche
de l’optimisation de la vitesse de trai-
tement. Plus une tâche s’exécute
rapidement, plus le système passe de
4 points
d’observation
Trace
d’interruption
Statistiques
CPU
Echantillonneur
ETM trigger
DWT
Accès en direct
au cœur
Jtag
SWD/SWO
Trace du port
DWT
Trace logicielle
sur 32 canaux
Time stamping
ITM
6 points
d’arrêt
FPB
Trace
des instructions
ETM
2 MODULE DE DÉBOGAGE DU CORTEX-M3/M4
Par le marquage temporel des données énergétiques
et des valeurs du compteur de programme, il est
possible au débogueur de présenter la consommation
sur le même axe des temps que les courbes
chronologiques d’arrivée des interruptions.
3 FENÊTRE « TIMELINE »
Une autre façon d’étudier les échantillons de consommation peut se faire
via la fenêtre « Timeline » où les mesures de puissance sont affichées sur l’axe des temps
avec les interruptions et quatre variables d’application à choisir.

30 / L’EMBARQUÉ / N°1
Application  Développement
temps dans les modes de basse
consommation. Ainsi en maximisant
le temps en mode inactif, on réduit
la consommation d’énergie.
Prenons quelques exemples mon-
trant combien il est difficile d’identi-
fier les mécanismes par lesquels un
système consomme de l’énergie sans
nécessité, et les zones de code se
prêtant à l’optimisation énergétique.
Typiquement, ce ne seront pas des
défauts explicites du code source qui
apparaîtront, mais plutôt des oppor-
tunités d’ajuster la manière d’utiliser
le matériel. Il peut arriver néanmoins
que des vraies fautes d’écriture du
code soient ainsi dénoncées.
Un exemple classique est l’attente du
changement d’état d’un dispositif. La
faute courante, pouvant générer une
consommation énergétique inutile,
consiste ici à utiliser une boucle de
lecture en attendant le changement
d’état d’un périphérique, par
exemple. Des segments de code
comme ceux présentés ci-dessous
s’exécutent sans interruption jusqu’à
ce que l’état bascule à la valeur
attendue :
while (USBD_GetState() < USBD_STATE_CONFIGURED);
while ((BASE_PMC->PMC_SR & MC_MCKRDY) != PMC_MCKRDY);
Un autre segment de code ayant le
même effet implante un retard logi-
ciel comme une boucle « for » ou
« while » :
i = 10000; // SW Delay
do i--;
while (i != 0);
Ces quelques lignes de code main-
tiennent le processeur en pleine acti-
vité pour exécuter des instructions
qui n’ont d’autre but que de faire
passer le temps.
Dans ces deux cas, il est possible de
modifier le programme pour minimi-
ser la consommation énergétique.
Ainsi, l’utilisation des compteurs
(timers) matériels est un moyen bien
plus efficace d’implanter des délais.
L’interruption du compteur est acti-
vée et le processeur passe en mode
basse consommation jusqu’à ce que
cette interruption le réveille. La lec-
ture des changements d’état de péri-
phérique doit, elle aussi, être gérée
à l’aide d’interruptions si possible, ou
avec l’interruption d’un compteur,
afin que le processeur puisse passer
en mode veille entre deux acquisi-
tions.
Selon les caractéristiques du système
embarqué, il peut être plus ou moins
difficile d’identifier les cas de figure
précédemment présentés. Un moyen
d’y arriver consiste à utiliser les diffé-
rentes fenêtres de débogage énergé-
tique afin de bien connaître le profil
de consommation de l’application
pour pouvoir détecter plus facilement
les comportements anormaux.
Prenons l’exemple des DMA versus
les E/S contrôlées. Dans ce cas, le
mode DMA sert traditionnellement
à augmenter la vitesse de transfert.
Les fabricants de microcontrôleurs
ont inventé toute une panoplie de
techniques DMA afin d’offrir plus de
souplesse et de vitesse, tout en dimi-
nuant la consommation. Dans cer-
taines architectures, le processeur
peut même être mis en sommeil
durant les transferts DMA. Avec le
débogage énergétique, le déve-
loppeur peut effectuer des essais et
comparer directement l’effet de ces
techniques DMA avec celui des
approches traditionnelles d’entrées/
sorties contrôlées par le processeur.
Poser un diagnostic
sur les modes à basse
consommation
De nombreuses applications embar-
quées passent la plus grande partie
de leur temps à attendre l’occurrence
d’un événement : l’arrivée d’une
donnée sur un port série, un change-
ment d’état sur une broche d’E/S, ou
l’expiration d’un délai. Si le proces-
seur reste à pleine vitesse en étant
inactif, il consomme l’énergie de la
batterie sans accomplir grand-chose.
En le plaçant en mode basse consom-
mation pendant ces temps d’inacti-
vité, la durée de vie du système peut
être nettement allongée.
Une bonne approche consiste à
structurer l’application en tâches et
à utiliser un système d’exploitation
temps réel. La technique multitâche
permet alors d’attribuer la plus faible
priorité à une tâche qui, dès lors,
s’exécutera uniquement lorsqu’au-
cune autre n’aura besoin du CPU. La
tâche « idle » est idéale pour instaurer
une telle gestion de l’énergie. A
chaque fois qu’elle est activée, elle
place le processeur dans un mode
basse consommation. De nombreux
microprocesseurs et autres compo-
sants possèdent plusieurs modes de
basse consommation qui désactivent
différentes zones du processeur
lorsque celles-ci ne sont pas néces-
saires au traitement en cours. Par
exemple, l’oscillateur sera désactivé
ou sa fréquence diminuée, les péri-
phériques et les compteurs seront
également désactivés, et le CPU
stoppera l’exécution d’instructions.
Ces modes ont chacun une consom-
mation différente selon les périphé-
riques laissés en activité.
Un outil de profilage énergétique
s’avère ici très utile pour examiner en
détail les divers modes de basse
consommation. Le profileur de fonc-
tion « Function Profiler » permettra,
par exemple, de comparer la
consommation de la tâche qui amène
le système dans le mode basse
consommation lorsque plusieurs
modes de mise en veille existent. La
valeur moyenne et le pourcentage de
la consommation totale sont autant
d’informations utiles pour effectuer
cette comparaison.
Contrôler la tension et
le fréquence du processeur
L’équation théorique donnant la
consommation d’un microcontrôleur
en technologie Cmos est la suivante :
P = f x U2 x k,
où f est la fréquence d’horloge, U la
tension d’alimentation et k une
constante.
Grâce au débogage énergétique, le
développeur peut étudier la consom-
mation en fonction de la fréquence.
Un système passant très peu de temps
en veille à 50 MHz est supposé être
50 % de son temps en veille s’il fonc-
tionne à 100 MHz. Les mesures de
4 FENÊTRE « FONCTION PROFILER »
La fenêtre « Function Profiler » indique la consommation de chaque fonction.

L’EMBARQUÉ / N°1 / 31
Développement  Application
consommation faites par le débo-
gueur permettront ainsi de vérifier le
comportement attendu et, en cas de
non linéarité par rapport à l’horloge,
de choisir la fréquence assurant la
plus faible consommation.
Une avancée technologique dans le
domaine des MCU permet,
aujourd’hui, de contrôler la valeur
de la tension interne U du cœur de
processeur à partir de l’application
même. Il est ainsi possible pour l’uti-
lisateur de réduire la valeur de la
tension interne VCORE de 1,8 V à
1,2 V si, dans le même temps, la fré-
quence de fonctionnement est ame-
née à 4 MHz maximum. Cette tech-
nique est absolument identique à
celle utilisée dans les processeurs
pour ordinateur portable ou de
bureau ; la technologie SpeedStep
mise au point par Intel en est un
exemple. La possibilité de contrôler
le paramètre tension dans l’équation
de la consommation est un nouvel
atout important pour intervenir dans
un système afin d’obtenir la plus
faible puissance consommée pos-
sible. Reportons nous au calcul théo-
rique : en réduisant la fréquence de
32 MHz à 4 MHz, la consommation
sera diminuée d’un facteur 8 ; si en
parallèle la tension de cœur VCORE
passe de 1,8 V à 2,2 V, alors la puis-
sance consommée est réduite d’un
facteur 18 !
Mieux gérer les interruptions
Voici un autre exemple où il est dif-
ficile de s’apercevoir qu’un système
consomme inutilement de l’énergie,
et qui implique cette fois les interrup-
tions.
La figure 5 montre la courbe de
consommation d’un système piloté
par événements qui, à t0, se trouve
en mode inactif avec une intensité I0.
A t1, le système est activé, ce qui fait
passer le courant I1, valeur qui repré-
sente la consommation du système
actif et se servant d’un périphérique.
A t2, l’exécution est suspendue par
une interruption de plus haute prio-
rité. Le périphérique en cours d’uti-
lisation n’est pas désactivé, bien que
la tâche ou thread de plus haute
priorité ne s’en serve pas. Au lieu de
cela, d’autres périphériques sont
activés par le nouveau thread, ce qui
augmente le courant et le fait passer
à la valeur I2 entre les instants t2 et t3,
moment où le contrôle est rendu au
thread de plus basse priorité.
La fonctionnalité du système est cer-
tainement excellente, ainsi que son
optimisation en termes de vitesse
d’exécution et de taille de code.
Mais au plan énergétique, des efforts
supplémentaires sont possibles. La
zone jaune sur la figure 5 représente
l’énergie économisée si les périphé-
riques inemployés entre t2 et t3 sont
désactivés, ou si les priorités entre les
deux threads sont échangées.
Le débogage énergétique fait donc
découvrir facilement la forte aug-
mentation de consommation corres-
pondant à l’arrivée d’interruption, et
permet d’identifier une anomalie. Un
examen approfondi dans la fenêtre
« Timeline » montre que des périphé-
riques inemployés restent actifs plus
longtemps que nécessaires et donc
consomment de l’énergie. Evidem-
ment dans une situation comme
celle décrite ci-dessus, il faudra tou-
jours vérifier si cela vaut la peine de
dépenser des cycles d’horloge sup-
plémentaires pour activer et désacti-
ver des périphériques.
Repérer les conflits
d’initialisation de matériel
Pour éviter les entrées « flottantes »,
une pratique courante de conception
consiste à raccorder à la masse les
broches d’entrées/sorties non utili-
sées par les microcontrôleurs. Si le
logiciel configure par erreur l’une de
ces broches en tant que sortie
logique à « 1 », un courant pouvant
atteindre 25 mA sera drainé à travers
cette broche. Il est facile de visualiser
cette valeur inexplicablement élevée
sur la courbe de consommation ; il
est aussi possible de retrouver le
code d’initialisation erroné corres-
pondant. Le tout en examinant l’al-
lure de la courbe de consommation
au moment du démarrage de l’appli-
cation. Une situation similaire se
présente si une broche d’E/S, conçue
comme entrée pilotée par un circuit
externe, est incorrectement configu-
rée en tant que sortie par le logiciel.
Attention aux interférences
dans les circuits analogiques
Implanter des circuits analogiques et
numériques sur une même carte
pose des problèmes bien particuliers.
Le placement-routage de la carte
joue à ce niveau un rôle important
dans le maintien de niveaux de bruit
assez bas pour garantir une acquisi-
tion précise des petits signaux analo-
giques. La conception en signal
mixte exige donc beaucoup d’atten-
tion et une grande expertise en déve-
loppement matériel. Mais la concep-
tion du logiciel peut, elle aussi,
affecter la qualité des mesures ana-
logiques. Le fait de programmer
l’exécution de multiples E/S pendant
l’acquisition de mesures analogiques
donne l’occasion à ces nombreuses
lignes numériques de basculer simul-
tanément ; ce qui représente une
bonne opportunité d’introduire du
bruit supplémentaire dans le conver-
tisseur analogique-numérique.
Un débogueur énergétique permet
ici d’examiner les interférences des
signaux numériques et d’alimenta-
tion au sein des composants analo-
giques. Dans la fenêtre « Timeline »,
il est facile d’afficher l’activité d’in-
terruption avec les données de
consommation, et d’étudier la
courbe de consommation juste avant
les interruptions du convertisseur
A/N. Les pics de consommation
parasite au voisinage des conver-
sions A/N peuvent être sources de
bruit et doivent être examinés. Toutes
les données de la fenêtre chronolo-
gique étant corrélées avec le code
exécuté, un simple double-clic sur la
valeur suspecte de la consommation
suffit à faire apparaître le code source
C correspondant.
On voit comment la méthodologie
de débogage énergétique analyse en
détail comment le logiciel applicatif
influence la consommation. Grâce à
ces données, il est alors possible
d’envisager une optimisation du
code source afin de minimiser la
consommation du système embar-
qué. n
I2 I2
I1
I0
t0t1t4 t3 t2
Temps
Consommation de puissance
5 DIAGRAMME DE LA PUISSANCE CONSOMMÉE
Ici, la zone jaune représente l’énergie économisée si
les périphériques inemployés entre t2 et t3 sont
désactivés, ou si les priorités entre les deux threads
sont échangées.