Samedi 2 décembre 2006
IntroductionLes méthodes pour le debug d’une application embarquée ont beaucoup évoluées. L’émulateur temps réel intrusif ( In circuit Emulator – ICE ) est largement supplanté par le debug OCD ( On Chip Debugging ) qui englobe les différentes appellations contrôlées que l’on peut voir çà et là : JTAG, BDM, OnCE, MPSD, SDI, OCDS etc …Le terme OCD recouvre toutes les méthodes qui utilisent des ressources ou un module spécifique du circuit permettant de réaliser le debug software et d’aider au debug de la partie hardware.
Historique
Dans les temps anciens ( à l'âge de pierre ), la première méthode qui a été utilisée c’est le « crash and burn », qui bien que l’expression soit imagée, consiste à programmer directement la mémoire avec le programme et tester si ça marche ; si cela ne marche pas, alors c’est l’effacement de la mémoire, modification du programme et re-programmation etc etc … on voit bien la limitation d’une telle méthode, car si ce n’est pas la patience du programmeur qui lâche, c’est le circuit mémoire qui va rendre l’âme.
Puis est venu le « debugger monitor » qui est un petit programme moniteur déjà présent ou programmé dans la mémoire programme de l’application. Ce moniteur permet de dialoguer, via une liaison série, avec un terminal ASCII alphanumérique. Le programmeur peut alors envoyer des commandes permettant de charger un programme ( par liaison série ), lire / écrire la mémoire, lire / écrire les registres, placer des points d’arrêts etc …Ces moniteurs ont longtemps été implantés sur les cartes à microprocesseurs dans le domaine industriel et grand public.
L’émulateur ROM ( ROM emulator ) a souvent été la solution à mi-chemin entre les méthodes précédentes et l’émulateur ICE. Peu coûteux ( par rapport à un ICE ), il permet de remplacer les mémoires programme de l’application ( ROM, FLASH, UVPROM, PROM ), par des sondes ayant la même empreinte. La plupart du temps il s’agit d’une mémoire de type SRAM que l’application voit comme une mémoire ROM. L’avantage principal c’est que l’on peut charger très rapidement et autant de fois que l’on veut le programme d’application : c’est la méthode « crash and burn » avec les inconvénients en moins. Associé à un moniteur, cette méthode flexible permet d’optimiser le debug.
L’émulateur ICE reste le must en matière de debug ; en effet, sa fonction principale étant de remplacer broche à broche le microprocesseur pour lequel il est conçu, les possibilités sont énormes : en plus des traditionnelles fonctions classiques d’un debugger ( accès mémoire, trace, point d’arrêt, registres ) il peut se transformer en analyseur logique, piloter chaqu'un des signaux, analyser des temps d’accès / d’exécution etc … Il permet à la fois de faire du debug sur le programme, mais aussi sur le matériel puisqu’il a un accès direct à tous les signaux « vitaux » du système, puisque architecturé autour d’un microprocesseur. La contrepartie c’est un coût élevé, exponentiel avec la complexité du processeur supporté. De plus l’adaptation à la cible s’avère aussi coûteuse ( connectique, sonde d’émulation, adaptation d’empreinte ), la mise en œuvre de l’ensemble restant assez lourde ( dans tous les sens du terme )
Le debug OCD très à la mode actuellement, supplante largement les autres méthodes vues ci-avant du fait de sa simplicité de mise en œuvre et de son faible coût : le processeur est relié au système de développement via 1 à une dizaines de signaux spécifiques issus du processeur et interfacé par l’intermédiaire d’un petit boîtier externe appelé sonde / pod JTAG, BDM, OnCE ou autre. Le processeur dispose d’un module interne piloté par des commandes et qui permet d’accéder aux ressources du processeur. Exemple sur le cœur CPU32 Freescale :
RAREG / RDREG : lecture registres adresse ou donnée
WAREG / WDREG : écriture registres adresse ou donnée
RSREG : lecture registre de contrôle système
WSREG : écriture registre de contrôle système
READ / WRITE : lecture / écriture mémoire
DUMP / FILL : lecture / écriture bloc mémoire
GO : exécution programme
RST : reset processeur
Un retour aux sources car cela ressemble au moniteur de debug vu ci avant, mais cette fois il est directement intégré au microprocesseur avec un micro-code et une machine d’état.
Afin de tenter de supplanter définitivement l’émulateur ICE, certains fabricants intègre une autre interface sur les processeurs appelée ETM ( Real Time Trace ) qui permet comme son non l’indique de tracer en temps réel les signaux du processeur et d’avoir ainsi un analyseur logique intégré.
Même si les sondes OCD et ETM pour les derniers processeurs sont coûteuses, il n’en reste pas moins que c’est une bonne alternative à une solution ICE. De plus les évolutions au sein d’une même famille de processeur ou le changement de processeur reste simple et se résume souvent à une mise à jour logiciel ; le connecteur d’interface type JTAG ou BDM par exemple, restant identique.
Le futur est déjà là avec la norme NEXUS obtenu par la fusion de l’OCD et de l’ETM avec la même interface. NEXUS se veut un vrai standard « the global embedded processor debug interface ». L’interface physique étant du JTAG et non un pseudo JTAG comme l’interface BDM par exemple. Souhaitons que ce standard en devienne vraiment un auprès des différents fabricants de processeurs, où il y règne toujours une certaine anarchie.
Tags : JTAG - FREESCALE - ABATRON - NEXUS5001

Développement durable, recyclage, environnement, pollution, des mots que l’on entend souvent en ce moment. Ces derniers mois les médias on régulièrement fait état du recyclage des appareils électroniques et électroménagers. Ce recyclage est la conséquence directe de l’application de la
La directive
On va s'arrêter là, après la sortie du Pentium qui marque l'entrée
dans l'ère actuelle. Mais rendons hommage aux anciens combattants comme le 8051 ou le 68000 par exemple : ce dernier, sorti en 1979, est toujours là avec une version à 8 Mhz pour 4 $ environ et au
maximum 2 MIPS à 20 Mhz. Chez
Une bonne nouvelle pour les programmeurs : en présence d’un bug aléatoire et difficilement compréhensible, ils pourront lâcher : « c’est à cause des rayons cosmiques ! ! ! ». Élucubrations, aberrations, … NON, le phénomène est bien connu et depuis longtemps : dans l’espace, satellites et véhicules spatiaux doivent résister aux bombardements incessant de