Fabrication industrielle
Internet des objets industriel | Matériaux industriels | Entretien et réparation d'équipement | Programmation industrielle |
home  MfgRobots >> Fabrication industrielle >  >> Industrial Internet of Things >> Embarqué

Implémentation JTAG dans les appareils Arm Core

Cet article vous expliquera l'intersection entre les périphériques JTAG et Arm, avec une attention particulière portée à l'interface de débogage Arm ou ADI.

Jusqu'à présent, dans notre série sur JTAG, nous avons examiné la norme IEEE 1149.1, y compris le contrôleur de port d'accès de test (TAP) et la machine d'état TAP. Ensuite, nous avons passé en revue les différentes interfaces physiques disponibles pour travailler avec JTAG, y compris les brochages courants pour les connecteurs, ainsi que les interfaces JTAG et les sondes de débogage disponibles sur le marché.

Dans cet article, nous allons nous écarter légèrement de la norme JTAG et examiner à la place comment JTAG est implémenté dans les périphériques de base ARM omniprésents.

Qu'est-ce que le bras ?

Arm fait référence à une architecture de processeur, ainsi qu'à une grande quantité de propriété intellectuelle relative aux interfaces de microprocesseur et de microcontrôleur. Là où les PC grand public ont tendance à utiliser des processeurs dérivés du x86, ou PowerPC, ou MIPS, l'électronique embarquée est le plus souvent mise en œuvre avec des processeurs Arm-core.

Le « cœur » des processeurs est distribué à des fabricants tels que ST Microelectronics ou NXP, et ces fabricants ajoutent ensuite des fonctionnalités périphériques supplémentaires, telles que des interfaces I2C et SPI, des ADC et DAC, des interfaces USB, etc.

Les architectures Arm sont versionnées en tant qu'ARMv, des exemples étant ARMv2 (datant de 1987), ARMv6 (processeurs produits en 2002-2005), etc. plus récemment en tant que série ARM Cortex-A/R/M pour les applications hautes performances (Cortex-A), temps réel (Cortex-R) et microcontrôleurs (Cortex-M). La gestion des versions de l'architecture suit le nom du suffixe Cortex, devenant des versions telles que ARMv6-M, ARMv7-R, ARMv7-A.

L'interface de débogage d'Arm porte le nom d'Architecture Arm CoreSight ; cela inclut l'interface de débogage (Arm Debug Interface, ADI), les macrocellules de trace intégrées (ETM), les ports de trace série haute vitesse (HSSTP) et l'architecture de trace de flux de programme CoreSight. L'ADI constitue la base des opérations de débogage avec les processeurs Arm-core, et une partie de cette norme comprend une interface JTAG ainsi que l'alternative Serial Wire Debug (SWD). Le sujet de cet article est l'ADI, et en particulier les couches d'interface matérielle.

Introduction à l'interface de débogage Arm (ADI)

L'interface de débogage d'armement (ADI) est une spécification à la fois de l'interface matérielle et de l'interface logique pour le débogage entre un hôte et un ou plusieurs périphériques. Actuellement, la plupart des processeurs implémentent ADIv5 (spécifié dans Arm IHI0031E), tandis que le plus récent ADIv6 (voir Arm IHI0074C) est progressivement introduit. Parce qu'il est plus populaire, nous nous concentrerons ici sur la norme ADIv5.

L'ADI définit un port d'accès de débogage (DAP), composé d'un port de débogage (DP) et de ports d'accès (AP). Le DAP est la principale « unité » de l'interface de débogage. Un périphérique donné aura un port de débogage, qui gère la connexion physique avec un débogueur, ainsi qu'un certain nombre de ports d'accès qui donnent accès aux ressources système telles que les registres de débogage, les registres de port de trace, une table ROM ou la mémoire système. Ainsi, le DP comprend la connexion physique (JTAG, SWD) ainsi que certains registres intégrés, et chaque AP a ses connexions au système et un certain nombre de ses propres registres.

Dans ADIv5, il existe deux types de ports de débogage et (de manière générale) trois types de ports d'accès. Les DP peuvent être soit des JTAG-DP, soit des SWD-DP, nommés pour l'interface utilisée pour se connecter au DAP depuis l'extérieur de l'appareil. Les points d'accès peuvent être des points d'accès MEM, fournissant un accès aux ressources par adressage (analogue au mappage de la mémoire, d'où le nom), des points d'accès JTAG, permettant aux chaînes de numérisation JTAG d'être connectées à l'ensemble de l'unité de débogage (le DAP) et spécifiques au fournisseur Les points d'accès, qui ne sont pas spécifiés par Arm. Les MEM-AP sont de loin les plus courants et les plus utiles, nous ne couvrirons donc pas les autres types ici.

Dans le contexte de JTAG, nous nous attendrions à ce que l'interface de débogage fournisse des codes d'instruction JTAG, ainsi que des fonctionnalités JTAG spécifiques au fournisseur. En fait, la norme ADIv5 fournit les instructions suivantes :

De plus, les registres de données JTAG incluent :

Ce qui doit ressortir ici, ce sont les instructions DPACC et APACC, et les registres de données associés. DPACC (Debug Port Access) et APACC (Access Port Access) sont les instructions/registres utilisés pour transmettre les commandes au DP et aux AP associés d'un périphérique. En définissant différentes valeurs dans les registres de données DPACC ou APACC, le débogueur peut exécuter différentes opérations, interagissant généralement avec les registres du DP et des AP eux-mêmes. Notez la différence entre ces registres DPACC et APACC (registres JTAG) et les registres intégrés aux DP et AP.

La méthodologie générale ici est que le débogueur utilise l'interface JTAG ou SWD pour exécuter des instructions en passant par la machine d'état TAP, puis les instructions prennent les données et les chargent dans le DP ou un AP, et selon les données, différents registres au sein le DP ou l'AP sont accédés, fournissant le lien désiré au système.

Alors, que sont les registres DP et AP ? Les registres DP disponibles incluent :

Alors que les registres MEM-AP sont :

Les connexions sont représentées schématiquement sur la figure 1 ci-dessous.

Figure 1. Armer le schéma de l'interface de débogage, résumant les connexions. Remarque :tous les registres ne sont pas affichés pour les DP et les points d'accès.

Les détails des registres DP/AP et le mappage de la mémoire peuvent être trouvés dans la spécification, IHI 0031E. Au lieu d'aller plus loin dans les détails, je voudrais me concentrer sur l'autre type de port de débogage, le SWD-DP, et comment il implémente JTAG en utilisant seulement deux fils.

Débogage du câble série (SWD)

Alors que le JTAG-DP est un exemple courant et familier d'interface de débogage, le plus pertinent pour notre discussion est l'alternative JTAG définie pour les appareils Arm, le Arm Serial Wire Debug (SWD). SWD a été développé comme une interface à deux fils pour les appareils Arm-core avec un nombre de broches limité. Comme les microcontrôleurs ont tendance à être assez denses dans les périphériques, la plupart des appareils Cortex-M implémenteront SWD à la place du JTAG complet pour économiser l'espace des broches. Alors comment fonctionne ce protocole ?

SWD est spécifié dans la spécification ADIv5 (chapitre B4). Les broches TDI et TDO de JTAG sont remplacées par une seule broche bidirectionnelle appelée SWDIO; la broche de sélection du mode de test (TMS) est entièrement supprimée ; et l'horloge (TCK) reste la même (rebaptisée CLK ou SWCLK). Ainsi, SWD n'utilise que deux broches par rapport aux quatre broches utilisées dans JTAG. Pour que cela fonctionne, SWD s'appuie sur la nature répétitive des opérations JTAG :la machine d'état est manipulée, les données sont déplacées vers l'intérieur ou l'extérieur et le processus se répète. La différence avec SWD est qu'il n'y a pas de machine à états. Au lieu de cela, les commandes sont émises en série sur SWDIO, puis cette même broche est utilisée pour lire ou écrire des données.

La communication SWD comporte trois phases :la demande de paquet, l'accusé de réception et le transfert de données. Pendant la demande de paquet, la plate-forme hôte envoie une demande au DP, et celle-ci doit être suivie d'une réponse d'accusé de réception. Si la demande de paquet était une demande de lecture ou d'écriture de données, et qu'il y avait un accusé de réception valide, le système entre dans la phase de transfert de données, où les données sont cadencées (écriture) ou cadencées (lecture) via SWDIO. Après un transfert de données, l'hôte est responsable soit du démarrage d'une demande de paquet, soit du pilotage de l'interface SWD avec des cycles d'inactivité (synchronisation SWDIO LOW). Un contrôle de parité est appliqué aux demandes de paquets et aux phases de transfert de données.

Les particularités de SWD sont mieux comprises en voyant un chronogramme, illustré à la figure 2.

Figure 2. Chronogrammes montrant les opérations de lecture et d'écriture pour le débogage de câble série. [Cliquez pour agrandir]

Les opérations de lecture et d'écriture commencent toutes les deux de la même manière, en commençant par l'hôte conduisant la ligne SWDIO à un bit de démarrage, qui est un signal HAUT. Ceci est suivi par la configuration, y compris le bit d'accès AP ou DP (APnDP), le bit de lecture ou d'écriture (RnW), l'adresse (A[2:3]), un bit de parité (PAR) et un bit d'arrêt ( un signal BAS), suivi enfin d'un bit de parcage, c'est-à-dire lorsque l'hôte entraîne la ligne HAUT avant que la ligne ne se retourne. Pendant le retournement, ni la cible ni l'hôte ne sont autorisés à conduire la ligne.

Selon la valeur de RnW, une opération de lecture ou d'écriture est sélectionnée. En cas d'écriture, la cible fournit un signal ACK 3 bits, puis il y a une autre période d'exécution, suivie des données 32 bits à écrire (WDATA) et d'un bit de parité. En cas de lecture, la cible fournit un ACK, puis continue à piloter la ligne avec les données de lecture 32 bits (RDATA), suivies d'un bit de parité. Si une erreur s'est produite, les bits ACK indiqueront le défaut et l'hôte peut tenter de redémarrer l'opération. Observez que WDATA et RDATA sont transmis en premier sur le bit le moins significatif (LSb), indiqué sur la figure 2 en écrivant WDATA[0:31] au lieu de WDATA[31:0].

Le document Arm IHI0031E fournit des chronogrammes supplémentaires pour clarifier divers cas de communication, mais ceux ci-dessus sont les principaux cas d'utilisation. Il convient de noter qu'il existe (au moment de la rédaction) deux versions de SWD ; SWDv1 ne prend en charge qu'une seule connexion entre un hôte et une cible (point à point), tandis que SWDv2 implémente une communication à plusieurs cibles à hôte unique (multipoint). La version 2 est presque rétrocompatible avec la version 1, à l'exception de quelques cas extrêmes.

Autres variantes de JTAG

SWD n'est pas la seule variante à deux fils de la norme JTAG IEEE 1149.1. Notamment, la norme IEEE 1149.7 fournit une interface JTAG à nombre de broches réduit (2 fils). D'autres normes 1149.x telles que IEEE 1149.4 (Standard for Mixed-Signal Test Bus) et IEEE 1149.6 (Standard Boundary-Scan des réseaux numériques avancés) ont été développées au cours des deux dernières décennies et fournissent des fonctionnalités supplémentaires pour les applications plus complexes. Cela inclut des éléments tels que les tests analogiques de balayage périphérique et des capacités améliorées pour les lignes différentielles et couplées en courant alternatif.

Les normes les plus récentes sont disponibles sur le site Web de l'IEEE Standards Association.

Conclusion

Ceci conclut notre couverture de JTAG et SWD. Tout au long de cette série, nous avons appris d'où vient JTAG, comment il fonctionne et comment il est utilisé pour déboguer et programmer des appareils. Nous avons examiné les connexions physiques pour JTAG, y compris les connecteurs et les interfaces disponibles, à la fois commerciaux et open source. Enfin, nous avons conclu avec un aperçu de la mise en œuvre de JTAG pour les technologies de cœur de processeur Arm, y compris l'interface à deux fils SWD.

À partir de là, nous pouvons utiliser en toute confiance les fonctionnalités de débogage et de programmation de nos appareils embarqués, en apprenant les détails des différentes implémentations et en utilisant au mieux notre temps.


Embarqué

  1. Arm permet des instructions personnalisées pour les cœurs Cortex-M
  2. Mise sous tension fiable d'un appareil médical à piles
  3. Souris :les IMU ADIS1647x ​​améliorent la navigation dans les appareils IoT
  4. ams pour faciliter la mise en œuvre de la technologie de détection optique 3D
  5. Marvell étend son partenariat stratégique avec Arm
  6. Surveillance des progrès des dispositifs médicaux
  7. Le contrôleur de moteur intègre le noyau Arm Cortex-M0
  8. Les émetteurs-récepteurs RS-485 isolés simplifient la conception
  9. Arm étend la connectivité IoT et les capacités de gestion des appareils avec l'acquisition de Stream Technologies