JTAG-implementatie in Arm Core-apparaten

Dit artikel leert u over de kruising tussen JTAG en Arm core-apparaten, met speciale aandacht voor de Arm Debug Interface of ADI.

Tot nu toe hebben we in onze serie over JTAG gekeken naar de IEEE 1149.1-standaard, inclusief de testtoegangspoort (TAP) -controller en de TAP-statusmachine. Vervolgens hebben we de verschillende fysieke interfaces bekeken die beschikbaar zijn voor het werken met JTAG, inclusief gemeenschappelijke pin-outs voor connectoren, en de JTAG-interfaces en debug-sondes die op de markt verkrijgbaar zijn.

In dit artikel gaan we enigszins afwijken van de JTAG-standaard en kijken we in plaats daarvan naar hoe JTAG wordt geïmplementeerd in de alomtegenwoordige ARM-kernapparaten.

Wat is arm?

Arm verwijst naar een processorarchitectuur, samen met een grote hoeveelheid intellectueel eigendom met betrekking tot microprocessor- en microcontrollerinterfaces. Waar consumenten-pc's de neiging hebben om x86-afgeleide processors of PowerPC of MIPS te gebruiken, wordt embedded elektronica meestal geïmplementeerd met Arm-core-processors.

De "kern" van de processors wordt gedistribueerd naar fabrikanten zoals ST Microelectronics of NXP, en deze fabrikanten voegen vervolgens extra randfuncties toe, zoals I2C- en SPI-interfaces, ADC's en DAC's, USB-interfaces, enzovoort.

Arm-architecturen hebben een versie als ARMv, voorbeelden zijn ARMv2 (daterend uit 1987), ARMv6 (processors geproduceerd in 2002-2005) enzovoort, en de processorkernen die deze architecturen gebruiken, worden gebrandmerkt als ARMx-serie (ARM1, ARM6, ARM7), en meer recentelijk als ARM Cortex-A/R/M-serie voor high-performance (Cortex-A), real-time (Cortex-R) en microcontroller (Cortex-M) toepassingen. De architectuurversies volgen de Cortex-achtervoegselnaamgeving en worden versies als ARMv6-M, ARMv7-R, ARMv7-A.

De debugging-interface van Arm valt onder de naam Arm CoreSight Architecture; dit omvat de debug-interface (Arm Debug Interface, ADI), embedded trace macrocells (ETM), high-speed seriële traceerpoorten (HSSTP) en CoreSight-programmastroomtraceringarchitectuur. De ADI vormt de basis voor debugging-operaties met Arm-core-processors, en een deel van deze standaard omvat een JTAG-interface en het alternatief Serial Wire Debug (SWD). Het onderwerp van dit artikel is de ADI, en met name de hardware-interfacelagen.

Inleiding tot de Arm Debug Interface (ADI)

De Arm Debug Interface (ADI) is een specificatie van zowel de hardware-interface als de logische interface voor het debuggen tussen een host en een of meer apparaten. Momenteel implementeren de meeste processors ADIv5 (gespecificeerd in Arm IHI0031E), terwijl de nieuwere ADIv6 (zie Arm IHI0074C) langzaam wordt ingevoerd. Omdat het populairder is, concentreren we ons hier op de ADIv5-standaard.

De ADI definieert een debug-toegangspoort (DAP), bestaande uit een debug-poort (DP) en toegangspoorten (AP's). De DAP is de primaire "eenheid" van de foutopsporingsinterface. Een bepaald apparaat heeft één debug-poort, die de fysieke verbinding met een debugger afhandelt, evenals een aantal toegangspoorten die toegang bieden tot systeembronnen zoals debug-registers, trace-poortregisters, een ROM-tabel of systeemgeheugen. Dus de DP omvat de fysieke verbinding (JTAG, SWD) evenals enkele ingebouwde registers, en elke AP heeft zijn verbindingen met het systeem en een aantal van zijn eigen registers.

In ADIv5 zijn er twee soorten foutopsporingspoorten en (in grote lijnen) drie soorten toegangspoorten. De DP's kunnen JTAG-DP's of SWD-DP's zijn, genoemd naar de interface die wordt gebruikt om van buiten het apparaat verbinding te maken met de DAP. De AP's kunnen MEM-AP's zijn, die toegang bieden tot bronnen door adressering (analoog aan geheugentoewijzing, vandaar de naam), JTAG-AP's, waardoor JTAG-scanketens kunnen worden aangesloten op de hele debug-eenheid (de DAP), en leverancierspecifieke AP's, die niet zijn gespecificeerd door Arm. MEM-AP's zijn verreweg het meest gebruikelijk en nuttig, dus we zullen de andere typen hier niet behandelen.

In de context van JTAG verwachten we dat de Debug Interface JTAG-instructiecodes biedt, evenals leverancierspecifieke JTAG-functies. In feite geeft de ADIv5-standaard de volgende instructies:

• EXTEST (0b00000000)
• VOORBEELD (0b00000001)
• VOORLOAD (0b00000010)
• INTEST (0b00000100)
• KLEM (0b0000101)
• HIGHZ (0b00000110)
• AFBREKEN (0b11111000)
• DPACC (0b11111010)
• APACC (0b11111011)
• IDCODE (0b11111110)
• BYPASS (0b11111111)

Ook bevatten de JTAG-gegevensregisters:

• ABORT (35 bits), registreer om een ​​toegangspoort af te breken
• DPACC (35 bits), Debug Port lees-/schrijftoegangsregister
• APACC (35 bits), toegangspoort lees-/schrijftoegangsregister
• IDCODE (32 bits)
• BYPASS (1 bit)

Wat hierbij op moet vallen zijn de instructies DPACC en APACC, en de daarbij behorende dataregisters. DPACC (Debug Port Access) en APACC (Access Port Access) zijn de instructies/registers die worden gebruikt om opdrachten door te geven aan de bijbehorende DP en AP's van een apparaat. Door verschillende waarden in de DPACC- of APACC-gegevensregisters in te stellen, kan de debugger verschillende bewerkingen uitvoeren, in het algemeen in wisselwerking met de registers van de DP en AP's zelf. Let op het verschil tussen deze DPACC- en APACC-registers (JTAG-registers) en de registers die in de DP's en AP's zijn ingebouwd.

De algemene methodologie hier is dat de debugger de JTAG- of SWD-interface gebruikt om instructies uit te voeren door de TAP-statusmachine te doorlopen, waarna de instructies de gegevens nemen en deze in de DP of een AP laden, en afhankelijk van de gegevens, verschillende registers binnen de DP of AP worden benaderd, waardoor de gewenste koppeling met het systeem wordt verkregen.

Dus, wat zijn de DP- en AP-registers? De beschikbare DP-registers zijn:

• CTRL/STAT, gebruikt om statusinformatie over de DP te controleren en te verkrijgen
• DLCR, Data Link Control register, regelt de bedrijfsmodus van de Data Link
• DLPIDR, Data Link Protocol Identificatieregister, informatie over protocolversie
• DPIDR, Debug Port Identification-register, Debug Port-informatie
• EVENTSTAT, gebeurtenisstatusregister, gebruikt door het systeem om een ​​gebeurtenis te signaleren aan de externe debugger
• RDBUFF, Read Buffer register, biedt een leesbewerking; afhankelijk van DP (JTAG of SWD)
• SELECT, AP Select register, selecteert een toegangspoort en de actieve registerbanken met dat AP; selecteert de DP-adresbank
• TARGETID, geeft informatie over het doel wanneer de host is verbonden met een enkel apparaat

Terwijl MEM-AP registers zijn:

• Bedienings-/statuswoordregister (CSW, 0x00), bevat controle- en statusinformatie
• Transfer Address Register (TAR, 0x04), bevat het adres voor de volgende toegang tot het geheugensysteem of de systeembron
• Data Read/Write-register (DRW, 0x0C), stelt het lezen of schrijven van het adres in TAR in – als u DRW leest, wordt de toegang ingesteld op lezen; als u naar DRW schrijft, is de toegang ingesteld op schrijven
• Banked Data-registers (BD0 tot BD3, 0x10, 0x14, 0x18, 0x1C), bieden directe lees- of schrijftoegang tot vier 32-bits geheugenblokken, beginnend bij het adres in TAR
• Configuratieregister (CFG, 0xF4), informatie over MEM-AP-configuratie
• Debase Base Address-register (BASE, 0xF8), pointer naar geheugensysteem, ofwel het begin van een set debug-registers of het begin van een ROM-tabel
• Identificatieregister (IDR, 0xFC), identificeert de MEM-AP.

De aansluitingen zijn schematisch weergegeven in figuur 1 hieronder.

Figuur 1. Arm Debug Interface-diagram, waarin verbindingen worden samengevat. Let op:niet alle registers worden getoond voor DP's en AP's.

Details van de DP/AP-registers en de geheugentoewijzing zijn te vinden in de specificatie, IHI 0031E. In plaats van verder op de details in te gaan, zou ik me willen concentreren op het andere type debug-poort, de SWD-DP, en hoe het JTAG implementeert met slechts twee draden.

Seriële draadfoutopsporing (SWD)

Hoewel de JTAG-DP een algemeen en bekend voorbeeld is van een foutopsporingsinterface, is het meest relevant voor onze discussie het JTAG-alternatief dat is gedefinieerd voor Arm-apparaten, de Arm Serial Wire Debug (SWD). SWD is ontwikkeld als een tweedraadsinterface voor Arm-core-apparaten met een beperkt aantal pinnen. Omdat microcontrollers de neiging hebben om vrij compact te zijn in randapparatuur, zullen de meeste Cortex-M-apparaten SWD implementeren in plaats van volledige JTAG om pin-vastgoed te besparen. Dus hoe werkt dit protocol?

SWD wordt gespecificeerd in de ADIv5-specificatie (hoofdstuk B4). De TDI- en TDO-pinnen van JTAG worden vervangen door een enkele bidirectionele pin genaamd SWDIO; de testmodusselectie (TMS)-pin is volledig verwijderd; en de klok (TCK) blijft hetzelfde (opnieuw gelabeld CLK of SWCLK). SWD gebruikt dus slechts twee pinnen in vergelijking met de vier pinnen die in JTAG worden gebruikt. Om dit te laten werken, vertrouwt SWD op het repetitieve karakter van JTAG-bewerkingen:de toestandsmachine wordt gemanipuleerd, gegevens worden naar binnen of naar buiten verschoven en het proces herhaalt zich. Het verschil met SWD is dat er geen staatsmachine is. In plaats daarvan worden opdrachten serieel gegeven via SWDIO, en vervolgens wordt diezelfde pin gebruikt voor het lezen of schrijven van gegevens.

Er zijn drie fasen in SWD-communicatie:pakketverzoek, bevestiging en gegevensoverdracht. Tijdens pakketverzoek stuurt het hostplatform een ​​verzoek naar de DP, en dit moet worden gevolgd door een bevestigingsantwoord. Als het pakketverzoek een gegevenslees- of gegevensschrijfverzoek was, en er was een geldige bevestiging, gaat het systeem de gegevensoverdrachtfase in, waar gegevens worden ingeklokt (schrijven) of uitgeklokt (lezen) via SWDIO. Na een gegevensoverdracht is de host verantwoordelijk voor het starten van een pakketverzoek of voor het aansturen van de SWD-interface met inactieve cycli (klokken SWDIO LOW). Er wordt een pariteitscontrole toegepast op pakketverzoeken en fasen van gegevensoverdracht.

De bijzonderheden van SWD worden het best begrepen door een timingdiagram te zien, weergegeven in figuur 2.

Figuur 2. Timingdiagrammen met lees- en schrijfbewerkingen voor Serial Wire Debug. [Klik om te vergroten]

De lees- en schrijfbewerkingen beginnen beide hetzelfde, te beginnen met de host die de SWDIO-lijn naar een startbit stuurt, wat een HOOG signaal is. Dit wordt gevolgd door de configuratie, inclusief de AP- of DP-toegangsbit (APnDP), de lees- of schrijfbit (RnW), het adres (A[2:3]), een pariteitsbit (PAR) en een stopbit ( een LAAG signaal), gevolgd door een Park-bit, dat is wanneer de host de lijn HOOG aandrijft voordat de lijn in turnaround gaat. Tijdens de turnaround mag noch het doelwit, noch de gastheer de lijn besturen.

Afhankelijk van de waarde van RnW wordt een lees- of schrijfbewerking gekozen. Bij schrijven levert het doel een 3-bits ACK-signaal, daarna is er nog een doorlooptijd, gevolgd door de 32-bits gegevens die moeten worden geschreven (WDATA) en een pariteitsbit. Als het leest, geeft het doel een ACK en gaat dan verder met het aansturen van de lijn met de 32-bits leesgegevens (RDATA), gevolgd door een pariteitsbit. Als er een fout is opgetreden, geven de ACK-bits de fout aan en kan de host proberen de bewerking opnieuw te starten. Merk op dat WDATA en RDATA eerst de minst significante bit (LSb) worden verzonden, aangegeven in afbeelding 2 door WDATA[0:31] te schrijven in plaats van WDATA[31:0].

Het Arm IHI0031E-document biedt verdere timingdiagrammen om verschillende gevallen in de communicatie te verduidelijken, maar de bovenstaande zijn de primaire gebruiksscenario's. Het is vermeldenswaard dat er (op het moment van schrijven) twee versies van SWD zijn; SWDv1 ondersteunt slechts één verbinding tussen een host en een doel (point-to-point), terwijl SWDv2 single-host multiple-target communicatie (multidrop) implementeert. Versie 2 is bijna achterwaarts compatibel met versie 1, afgezien van enkele randgevallen.

Andere varianten van JTAG

SWD is niet de enige tweedraadsvariant van de JTAG IEEE 1149.1-standaard. Met name de IEEE 1149.7-standaard biedt een JTAG-interface met een verminderd aantal pins (2-draads). Andere 1149.x-standaarden zoals IEEE 1149.4 (Standard for Mixed-Signal Test Bus) en IEEE 1149.6 (Boundary-Scan Standard of Advanced Digital Networks) zijn in de afgelopen twee decennia ontwikkeld en bieden extra functionaliteit voor meer betrokken toepassingen. Dit omvat zaken als analoge grensscantesten en verbeterde mogelijkheden voor differentiële en AC-gekoppelde lijnen.

De meest actuele normen zijn beschikbaar op de website van de IEEE Standards Association.

Conclusie

Dit concludeert onze dekking van JTAG en SWD. Door deze reeks hebben we geleerd waar JTAG vandaan komt, hoe het werkt en hoe het wordt gebruikt om apparaten te debuggen en te programmeren. We hebben de fysieke verbindingen voor JTAG bekeken, inclusief de beschikbare connectoren en interfaces, zowel commercieel als open source. Ten slotte sloten we af met een overzicht van de JTAG-implementatie voor de populaire Arm-processorkerntechnologieën, inclusief de SWD-tweedraadsinterface.

Vanaf hier kunnen we eropuit gaan en vol vertrouwen de foutopsporings- en programmeerfuncties van onze ingebouwde apparaten gebruiken, de details voor verschillende implementaties leren kennen en onze tijd zo goed mogelijk gebruiken.