A JTAG (az azt leíró Joint Test Action Groupról elnevezve) technikai szabvány nyomtatott áramkörök gyártás utáni tesztelésére és tervezésük megerősítésére.
A JTAG chipen lévő műszerezési szabványokat fektet le az elektronikus tervezésautomatizáció (EDA) terén a logikai szimulációt kiegészítve.[1] Egy dedikált hibakereső port használatát írja le soros kommunikációs felülethez alacsony költségű hozzáféréshez a rendszercímhez és az adatbuszokhoz közvetlen külső hozzáférés nélkül. A felület chipen lévő teszthozzáférési porthoz csatlakozik, mely egy állapotokkal rendelkező protokollt ad meg a tesztregiszterek hozzáféréséhez, bizonyos eszközök logikai szintjeinek és képességeinek megadásához.
A Joint Test Action Group 1985-ben jött létre tervezések ellenőrzésére és nyomtatott áramkörök gyártás utáni ellenőrzésére. 1990-ben az Institute of Electrical and Electronics Engineers az eredményeket az IEEE Standard 1149.1-1990-ben (címe Standard Test Access Port and Boundary-Scan Architecture) írta le.
A JTAG-szabványokat számos félvezetőgyártó bővítette gyártóspecifikus funkciókkal bővítette.[2]
Történet
Az 1980-as években a gömbrácssoros többrétegű áramkörök és az integrált áramkörök szabványossá váltak, és a nem elérhető IC-k közt kapcsolatokat hoztak létre. A legtöbb gyártási hiba okai a nem megfelelő forrasztás, a csatlakozások hibája vagy az IC-padek és a tüskék közti csatlakozások és csatlakozók voltak. A Joint Test Action Group (JTAG) 1985-ben jött létre pinoutnézet létrehozásához egy IC-lapról egy másikra, lehetővé téve ezek felismerését.
A szabvány 1990-ben IEEE-szabvány lett IEEE Std. 1149.1-1990 számon[3] sok év használat után. Ez évben az Intel kiadta az első JTAG-es processzorát, a 80486-ot, gyorsabb elterjedéshez vezetve. 1994-ben a Boundary scan description language (BSDL) leírása is bekerült. További javítások a csak 0-kból álló érték EXTEST-re használásáról, a SAMPLE és a PRELOAD elválasztásáról és az OBSERVE ONLY javítása 2001-ben jelent meg.[4] 1990-től számos elektronikai cég használta a szabványt. A határelemzés nagyrészt szinonim a JTAG-gel, de utóbbinak a gyártáson túlmutató fontos használati területei is vannak.
Hibakeresés
Az FPGA-fejlesztésben is használatos JTAG hibakeresőeszköz-fejlesztésre.[5] A CPU-ban használt JTAG technikák egy FPGA más tervezési részeiben is alkalmasak hibakeresésre. Például egyéni JTAG-utasítások adhatók meg tetszőleges jelhalmazból való regiszterek olvasására az FPGA-ban, láthatóvá téve a határelemzéssel láthatatlan viselkedéseket. Ugyanígy a regiszterek írása másképp elérhetetlen funkciókat tesz elérhetővé.
Határelemző teszt
A JTAG egy komplex integrált áramkör számos logikai szignáljához hozzáférést nyújt, beleértve a tüskéket. A jelek a TAP révén elérhető regiszterben szerepelnek. Ez lehetővé teszi a tesztelést és a teszteléshez és hibakereséshez tartozó jelek állapotainak irányítását. Így a szoftver- és a hardverhibák is elhelyezhetők, és az eszköz vizsgálható.
Beépített önteszteléssel (BIST) kombinálva a JTAG ellenőrzési lánc költsége alacsony, egy IC hibáinak ellenőrzésére. Az ellenőrzési lánc általában nem segíti a diagnózist vagy ellenőrzi az időzítést, a hőmérsékletet vagy más dinamikus hibákat. A teszteseteket általában szabványos formátumokban, például SVF-ben vagy ennek bináris megfelelőjében, XSVF-ben adják meg. Az ilyen tesztelés lehetősége fontos a tesztre tervezésben, növelve a termékek elérhetősége előtt található hibák arányát.
Elektromos jellemzők
A JTAG-felület chiphez adott speciális felület, verziójától függően 2, 4 vagy 5 további tüskével. A 4 és 5 tüskés felületek tervezése révén lehetséges sorba kapcsolni a JTAG-csatlakozásokat bizonyos esetekben.[6] A 2 tüskés változat lehetővé teszi több chip csillagtopológiás csatlakozását. Mindkét esetben a tesztelő résznek egy „JTAG porthoz” kell csatlakoznia a chipekhez féréshez.
Sorba kapcsolt JTAG (IEEE 1149.1)
JTAG-lánc. A visszaállító jel nincs a képen
A csatlakozó tüskék:
TDI (Test Data In)
TDO (Test Data Out)
TCK (Test Clock)
TMS (Test Mode Select)
TRST (Test Reset) opcionális.
A TRST opcionális visszaállító a tesztlogikára, általában aszinkron, de lehet szinkron. Ha nem elérhető, a visszaállítási állapotra való szinkron váltással lehet visszaállítani a tesztlogikát a TCK és TMS révén. A tesztlogika visszaállítása nem szükségképp vált mást. Vannak processzorspecifikus JTAG-műveletek, melyek a chip részét vagy egészét visszaállíthatják.
Mivel csak 1 adatvonal érhető el, soros a protokoll. Az órabemenet a TCK tüskén van. A TDI-ről 1 bit kerül át, illetve 1 bit megy ki a TDO-ra a TCK pozitív élén. Különböző utasítások tölthetők be. Az IC-k jellemző utasításai beolvashatják a chipazonosítót, a bemeneteket, a kimeneteket, módosíthatnak chipfunkciókat vagy átugorhatnak.
Mint más órázott jelek esetén, a TDI-n adott adatnak bizonyos chipspecifikus Setup idővel a releváns időszak előtt és Hold idővel utána érvényesnek kell lennie. A TDO-adat a TCK negatív váltása után érvényes.
A TCK maximális frekvenciája a lánc minden chipjétől függ (a legalacsonyabb sebesség használandó), de általában 10-100 MHz. A TCK frekvenciái függnek továbbá a lap kinézetétől és a JTAG adapter képességeitől és állapotától. Egynek lehet 40 MHz-es JTAG órája, de csak ha 200 MHz-es órája van nem JTAG műveletekhez, és sokkal lassabb órát használhat energiatakarékos módban. Ennek megfelelően egyes JTAG adaptereknek adaptív órázásuk van RTCK jellel. A gyorsabb TCK frekvenciák a JTAG adatátvitelre való használatakor hasznosak.
Az óra a TMS lépéseinél szabványos JTAG eszközzel történik. Ez visszaállíthat, hozzáférhet utasításregiszterhez vagy az az által kiválasztott adathoz.
A JTAG platformok gyakran adnak jeleket az IEEE 1149.1 által meghatározottakhoz. A System Reset (SRST) jel gyakori, és lehetővé teszi a teljes rendszer újraindítását. Gyakran vannak eseményjelek gazda, a JTAG által felügyelt eszköz vagy további irányító vezetékek általi aktivitás-előidézésre.
Bár csak kevés fogyasztói eszköz ad JTAG portcsatlakozót, ez gyakran elérhető a nyomtatott áramkörön a prototípus-készítés vagy a gyártás során fennmaradt részként.
Csökkentett tüskeszámú JTAG (IEEE 1149.7)
Csökkentett tüskeszámú JTAG példája
A csökkentett tüskeszámú JTAG csak 2 csatlakozót, egy óra- és egy adatcsatlakozót használ. Ezt az IEEE 1149.7 szabvány határozza meg.[7] A tüskék:
TMSC (Test Serial Data)
TCK (Test Clock)
Nevezik cJTAG-nek (kompakt JTAG) is.
A kétcsatlakozós felület csökkenti a tüskeszámnyomást, és az eszközök csillagtopológiával csatlakoztathatók.[8] Ez lehetővé teszi a rendszer egyes részeinek kikapcsolását, míg mások hozzáférhetők JTAG-en, míg a lánctopológia minden JTAG felület hozzáférhetőségét igényli. Más kétcsatlakozós felületek is vannak, például a Serial Wire Debug.
Primitívek
A gazda a TAP-ekkel a TMS, a TCK és a TDI változtatásával, valamint az egyetlen gazdaoldali bemenet, a TDO eredményeinek kiolvasásával kommunikál. A TMS/TDI/TCK kimeneti átmenetek alkotják az alap JTAG kommunikációs primitívet, melyen felsőbb protokollok alapulnak:
Állapotváltás: Minden TAP azonos állapotban van, ez változik a TCK változásával. Ez az eszköz része a JTAG specifikációnak, és 16 állapotú. 6 „stabil állapot” van, ahol a TMS stabilitása megakadályozza az állapotváltozást. Más állapotokban a TCK mindig megváltoztatja az állapotot. A TRST lehetővé teszi egy stabil állapot elérését (Test Logic Reset) gyorsabban, mint a TMS magas állapotban tartása és a TCK 5-szöri ciklusa.
Eltolás: A legtöbb JTAG rész 2 adatátviteli stabil állapotot támogat. Minden TAP rendelkezik utasítás- (IR) és adatregiszterrel (DR). Ezek mérete TAP-enként eltér, és a TDI-vel és a TDO-val együtt nagy eltolási regisztert adnak (a DR mérete a TAP jelenlegi IR-ének és feltehetően a SCAN N utasítás által megadott értéktől is függ). 3 művelet van e regiszteren:
Ideiglenes érték rögzítése
Shift IR stabil állapotba lépés a Capture IR állapottal, mely az eltolóregisztert részben rögzített értékben tölti (nem a jelenlegi utasítással)
Shift DR stabil állapotba lépés a Capture DR állapottal, mely az adatregisztert tölti be, melyet a TAP IR-e ad meg.
Bitenkénti eltolás a Shift IR vagy a Shift DR állapottal. A TCK átmenetei 1 bittel tolják el a regisztert TDI-től TDO-ig, az SPI 1 módú adatbusz átviteléhez hasonlóan (TMS=0 a chip választójeleként, a TDI a MOSI-ként működik, stb.)
IR vagy DR frissítése az ideiglenes értékről az Update IR vagy Update DR állapoton való átmenettel. Nem olvasható (rögzíthető) regiszter írása (frissítés) nélkül, és fordítva. Gyakoriak a frissítés mellékhatásainak létét vagy azok végrehajtását jelző bitek.
Futtatás: Egy stabil állapot a Run Test/Idle. A megkülönböztetés TAP-specifikus. A TCK Idle állapotának nincs jelentős mellékhatása, de a Run Test állapot megváltoztathatja a rendszerállapotot. Például egyes ARM9 magok rendelkeznek hibakereső móddal, ahol a TCK ciklusok adják az utasítás-futószalagot.
Alapvetően a JTAG használata utasítások és megfelelő regisztereik olvasását és írását jelenti, valamint néha bizonyos számú tesztciklust. E regiszterek mögött a JTAG által nem meghatározott hardver van, saját, a JTAG-műveletek által befolyásolt állapotokkal.
Sok JTAG-gazda a két állapot közti legrövidebb, adott esetben az adapter működése által korlátozott utat használja. Egyes, a JTAG-re épülő rétegek figyelik az állapotváltásokat, és ritkább utakat használnak magasabb szintű műveletekre. Egyes ARM magok ilyen sorozatokat használnak kétcsatlakozós (nem JTAG) SWD módhoz. Egy Zero Bit Scan (ZBS) sorozat használatos az IEEE 1149.7-ben.[7] a további funkciók, például TAP- vagy ellenőrizetlenlánc-váltás, energiahasználat vagy eltérő kétcsatlakozós mód hozzáféréséhez.
JTAG IEEE Std 1149.1 (határelemzési) utasítások
Az utasításregiszter-méretek általában kicsik, 4-7 bitesek. A BYPASS és az EXTEST kivételével minden utasításkódot és kapcsolódó adatregisztert a TAP megvalósítója definiál; a nem definiált kódok nem használandók. Két fontos utasítás:
a BYPASS utasítás, csak 1-ekből álló kóddal a TAP IR-méretétől függetlenül, és minden TAP-nek támogatnia kell. 1 bites adatregisztert választ ki (ezt is nevezik BYPASS-nek). Az utasítás lehetővé teszi egy eszköz átugrását a többiek vizsgálatával.[4]
az opcionális IDCODE utasítás megvalósító által definiált kóddal. Ehhez 32 bites regiszter tartozik, adata szabványformátumot használ a gyártó kódjával (a JEDEC Standard Manufacturer's Identification Code (JEP-106) szabványa szerint), a gyártó által meghatározott részszámmal és a rész verziókódjával. Az IDCODE széles körben támogatott, de nem univerzális.
A RESET állapot elhagyása után az utasításregisztert a BYPASS vagy az IDCODE előtölti, lehetővé téve a JTAG-gazdáknak a hozzájuk kapcsolt elemzési lánc méretének teljes és tartalmának legalább részleges azonosítását (a RESET állapotba lépés után elemezhetik az adatregisztert az általuk írt adat visszaolvasásáig. Egy BYPASS regiszterben egy 0 van, az IDCODE viszont 32 bites, és 1-gyel kezdődik. Így a nem a gazda által írt bitek hozzárendelhetők a TAP-ekhez). Ez az azonosítás a kézi beállítás ellenőrzésére gyakran használatos, mivel az IDCODE gyakran nem specifikus. Például azonosíthat ARM Cortex-M3 alapú mikrovezérlőt annak gyártójának és modelljének megadása nélkül, vagy egy adott FPGA-t, de programozásának módját nem.
Gyakori a BYPASS beadása egy más utasítást kapó kivétellel minden TAP-be. Így egy kivétellel minden TAP adatregisztere 1 bites, és az értékek szelektíven adhatók e kivétel adatregiszterébe vagy vehetők ki onnan más TAP érintése nélkül.
Az IEEE 1149.1 (JTAG) szabvány számos utasítást határoz meg határelemzés-támogatásra. Ezek egy része szükséges, de a hibakeresésre használt TAP-ek ezeket részben vagy nem támogatják. Ezen utasítások a BSDL-fájlban definiált határelemző regiszteren működnek, és ezek az alábbi utasítások:
EXTEST külső tesztelésre, például tüskék áramköri viselkedésre használatához
PRELOAD kimeneti értékek EXTEST előtti beadásához (néha a SAMPLE-lel együtt)
SAMPLE a határelemző regiszterbe olvasáshoz
Az IEEE által definiált opcionális utasítások például:
CLAMP, a BYPASS változata, mely a kimeneti tüskéket előtöltött értékekkel irányítja
HIGHZ: a tüskék kimeneteit inaktiválja
INTEST: belső tesztelésre, például tüskék viselkedéstesztelésére
RUNBIST: a chipet öntesztelő módba állítja
USERCODE: felhasználó definiálta kódot ad ki például az aktív FPGA-képek azonosítására
Az eszközök további utasításokat definiálhatnak, ezeknek a gyártó által biztosított BSDL fájl részének kell lenniük. Gyakran PRIVATE-ként jelzik.
Határelemző regiszter
Az eszközök be- és kimeneti tüskék csoportjával kommunikálnak. Maguk a tüskék az eszköz működésének korlátozott részét fedik fel. Azonban a határelemzést támogató eszközök regisztereltoló cellát tartalmaznak az eszköz minden jeltüskéjéhez. E regiszterek önálló úton kapcsolódnak az eszköz határa mentén (innen a nevük). Az út virtuális, a normál be- és kimeneteket megkerülő elérési lehetőséget ad, lehetővé téve a közvetlen irányítást és a jelek részletes láthatóságát.[9]
A határelemző regiszter tartalmait általában a gyártó írja le részspecifikus BSDL fájlban. Ezeket tervezési hálólistákkal használják CAD/EDA rendszerekről a tesztek lapgyártásban való teszteléséhez. A kereskedelmi tesztrendszerek gyakran néhány ezer dollárosak, és a hibák, például a nyílt áramkörök és a zárlatok helyének meghatározására alkalmas eszközeik vannak. Ezenkívül sematikus vagy elrendezéses megtekintést is támogatnak a hiba grafikus megjelenítéséhez.
A határelemzés engedélyezéséhez az IC-gyártók logikát adnak minden eszközhöz, például elemzőcellákat a jelzőtüskékhez. E cellák összekapcsolódnak a határelemző eltolási regiszterhez (BSR), mely a TAP vezérlőhöz csatlakozik. Ezek sok Verilog és VHDL könyvtár részei. E további logika költsége kicsi.
Gyakori kiterjesztések
A mikroprocesszor-gyártók gyakran saját magspecifikus hibakeresési kiterjesztéseket határoztak meg. Ilyenek például az Infineon, a MIPS az EJTAG-gel stb. Ha a gyártó nem használ egy szabványt (például az ARM processzorok vagy a Nexus által használtat), saját megoldást kell használniuk. Határelemzés támogatása esetén általában JTAG-en alapul a hibakeresésük.
A Freescale rendelkezik COP és OnCE (On-Chip Emulation) kiterjesztéssel. Az OnCE tartalmaz egy JTAG parancsot, mely egy TAP speciális módba lépését okozza, ahol az IR OnCE hibakereső parancsokat tartalmaz[10] egyszeri keresésekre, töréspontokra és regiszter- vagy memória-hozzáférésre. Ezenkívül definiál EOnCE-t (Enhanced On-Chip Emulation)[11] is valós idejű problémák kezelésére.
Az ARM kiterjedt processzormag-hibakeresési architektúrával (CoreSight) rendelkezik, mely az EmbeddedICE-szal (a legtöbb ARM magon elérhető hibakereső) kezdődött, és számos további komponens jelent meg hozzá, például az ETM (Embedded Trace Macrocell) nagy sebességű követőporttal, többmagos és -szálas visszakövetéssel. A visszakövetés nem invazív: a rendszernek nem kell leállnia a visszakövetéshez, azonban a visszakövetési adat túl nagy a JTAG visszakövetés-irányítástól eltérő célokra való használatához.
A Nexus nagyrészt gyártófüggetlen infrastruktúrát kínál. Egy hardverfelülete a JTAG. Nagy sebességű külső portfelülete is van többek közt nyomkövetésre. A Nexust újabb platformok, például az Atmel AVR32 és a Freescale MPC5500 sorozat használják.
Használat
Néhány nagyon olcsó rendszer kivételével gyakorlatilag minden beágyazott rendszerben van JTAG port áramkörön belüli hibakeresésre, firmware-programozásra és határelemzésre:
Az ARM processzorok támogatják a JTAG-et, bizonyos esetekben 2 vezetékes SWD variánssal vagy nagy sebességű forgalomészleléssel utasítási vagy adatbuszokon.
A modern 8 és 16 bites mikrovezérlő chipek, például az Atmel AVR és a TI MSP430 támogatják a JTAG programozást és hibakeresést. Azonban a legkisebb chipekben nincs feltétlenül elég tüske, így saját egycsatlakozós felületeket használhatnak, ha több mint 32 tüske van, általában van JTAG lehetőség.
Számos FPGA és CPLD programozható JTAG porttal. A JESD-71 definiálja a Standard Test and Programming Language-et a PLD-k JTAG-programozásához.
Sok MIPS és PowerPC processzor támogatja a JTAG-et.
Az Intel Core, Xeon, Atom és Quark processzorok támogatják a JTAG próbamódot a JTAG Intel-specifikus bővítéseivel 60 tüskés XDP-vel (Extended Debug Port). Ezenkívül a Quark processzor támogatja a 10 tüskés csatlakozókat is.
A fogyasztói termékek, például a hálózati eszközök és a műholdas televízió integrált fogadó/dekódolói gyakran JTAG-et támogató mikroprocesszort használnak, a firmware újratöltését lehetővé téve a meglévő indítószoftver sérülésekor.
A PCI buszcsatlakozó-szabvány opcionális JTAG-jeleket tartalmaz az 1–5. tüskéken,[12] a PCI Express JTAG-jeleket tartalmaz az 5–9. tüskéken.[13] Speciális JTAG kártya használható sérült BIOS felülírására.
Határelemző teszt- és rendszeren belüli programozó alkalmazások írhatók Serial Vector Formattel, mely a JTAG-műveleteket szövegesen jeleníti meg egyszerű szintaxissal. További programformátumok például a JAM, a STAPL és az IEEE 1532-ben definiált ISC (In-System Configuration). Ez bővített BSDL-modellekkel együtt használatos programozható logikai eszközökhöz, melyek ISC_<művelet> utasításokat is tartalmaznak az IEEE 1149.1 utasítások mellett. A Xilinx, az Altera, a Lattice, a Cypress, az Actel stb. FPGA-programozó eszközei általában képesek ilyen fájlok exportálására.
Mint fent szerepelt, sok lapon van JTAG csatlakozó a gyártási műveletek támogatására, ahol a határvonal ellenőrzése segíti a lapminőség-ellenőrzést és a flash memória vagy FPGA-k inicializálását.
A JTAG támogathatja a mezőfrissítést és a hibakeresést.
Támogatás
A cél JTAG felülete JTAG-engedélyezett alkalmazással és JTAG adapterrel férhető hozzá. Számos ilyen hardver van különböző célokra, például termelési tesztelésre, gyors rendszerek hibakeresésére stb. Ugyanígy a hardver használta szoftver is sokféle lehet. A szoftverfejlesztők általában a firmware hibakeresésére és frissítésére használnak JTAG-et.
Nincs hivatalos szabvány a JTAG adapterek fizikai csatlakozóira. A fejlesztői lapok általában a preferált fejlesztői eszközöket támogató részt tartalmazzák, bizonyos esetekben többet is, mert több ilyen eszközt kell támogatni. Például egy mikrovezérlő, egy FPGA és egy ARM processzor eszközei ritkán azonosak, így egy mindegyiket használó fejlesztői lap 3 vagy több ilyen részt tartalmazhat. A gyártói lapokon nem szükségképpen vannak ezek jelen, vagy korlátozott hely esetén a JTAG-jelet tesztpontokkal biztosíthatják.
MIPI10-/20-csatlakozók (1,27 mm) JTAG-hez, cJTAG-hez és SWD-hez
E csatlakozók általában a 4 szabványos jelnél többet támogatnak. Általában vannak visszaállító jelek, a TRST és az SRST legalább egyike. A csatlakozó a tesztelendő lap logikai forrásfeszültségét adja, így a JTAG adapterek a megfelelő logikai szinteket használják. A lap feszültsége lehet „lap jelen” hibakereső-bemenet. Más eseménybe- és -kimeneti jelek vagy általános célú I/O (GPIO) vonalak is lehetnek összetettebb hibakereső-architektúrákhoz.
A felsőbb kategóriás termékek gyakran sűrű csatlakozókat (általában 38 tüskés MICTOR csatlakozók) nagy sebességű visszakövetés támogatására a JTAG műveletekkel együtt. Újabb trend a fejlesztői lapok USB-felület-integrálása JTAG-re, ahol másik csatorna használatos soros portra (kisebb lapok is használhatók USB-n. Mivel az újabb számítógépeken jellemzően nincs soros port, ezen integrált hibakereső csatlakozók csökkenthetik a rendezetlenséget). A végleges lapok gyakran „szöges ágy” csatlakozásokat használnak tesztelésre és programozásra.
Adapterhardver
Az adapterhardver igen változékony. Ha nincs fejlesztői lapba integrálva, a JTAG-csatlakozóhoz kapcsolható rövid kábele van a céllapon, egy csatlakozója a hibakeresőre, például USB, PCI vagy Ethernet kapcsolat, és elég elektronika a két kommunikációs tartományhoz (adott esetben galvánizolációval). Külön áramforrás szükséges lehet. Vannak adapterek, ahol a gazda dönt el és végez minden JTAG műveletet, és vannak, ahol ezek egy része az adapteren belül történik, gyakran mikrovezérlővel. Ez utóbbiak esetén kisebb a kapcsolati késés az állapotváltozásokat lekérdező műveletsoroknál, ennek megfelelően nagyobb lehet az átviteli sebességük.
2018-ban az USB-csatlakozós adapterek voltak a leggyakoribbak. A nagyobb árú eszközök gyakran támogatnak Ethernetet, így a gazda távolabb is lehet. A nagy sebességű nyomkövető portot támogató adapterekben általában néhány MB puffer van, és az adatátvitelhez is nagy sebességű portot használnak.
A párhuzamosport-adapterek egyszerűek és olcsóak, de lassúak, mivel a gazdaprocesszort használják bitváltásokra. Csökkent használatuk, mivel a legtöbb számítógépen nincs párhuzamos port. Driver support is also a problem, because pin usage by adapters varied widely. Since the parallel port is based on 5V logic level, most adapters lacked voltage translation support for 3.3V or 1.8V target voltages.
RS-232 soros portra is vannak adapterek, de használatuk is hasonlóan csökken. Általában vagy lassabb bitváltásúak a párhuzamos portnál, vagy egy parancsprotokollt JTAG műveletekre alakító mikrovezérlők. Ezek nem gyorsak, de protokolljaik gyorsabb kapcsolatokon alapulva használhatók.
Mint minden JTAG adapter esetén, a szoftvertámogatás alapvető. Sok gyártó nem adja ki a JTAG-adapterük által használt protokollt, így csak az általuk támogatott eszközláncok használhatók. Ez különösen fontos az „okos” adaptereknél, melyek egy része számos információt ad az egyes processzorokkal való kommunikációról.
Szoftverfejlesztés
A legtöbb beágyazott fejlesztői környezet rendelkezik JTAG-támogatással. Tág értelemben 3 ilyen szoftverforrás van:
A chipszolgáltatók adják az eszközöket, ehhez általában a hozzá adott JTAG adapter kell. Ilyenek például az FPGA-gyártók, például a Xilinx és az Altera, az Atmel az AVR8 és AVR32 terméksorozataihoz és a Texas Instruments a legtöbb DSP és mikrotermékhez. Ezek általában sokfunkciósak, és az egyetlen megfelelő lehetőség lehetnek nagyon specializált chipekhez. A kevesebb funkciós eszközök ingyenesek is lehetnek. Az adapterek nem ingyenesek, de néha fejlesztői lapokkal együtt adják.
Az eszközszolgáltatók gyakran több chipszolgáltatóval együtt adják az eszközöket a platformfüggetlen fejlesztés támogatásához. Az ARM-alapú termékek esetén ez sok, különösen harmadik fél eszközei esetén, és számos szolgáltató nem ARM platformokra, például MIPS-re és PowerPC-re is terjeszkedett. Az eszközszolgáltatók bizonyos esetekben szabad szoftverre, például GCC és GDB-re alapozzák szoftverüket, a GUI-támogatáshoz gyakran Eclipse-et használnak. A JTAG-adapterek bizonyos esetekben támogatócsomaggal érkeznek.
Vannak nyílt forrású eszközök. Ahogy fent szerepel, a GCC és GDB részei egy jó eszközláncnak, és vannak ezt támogató GUI környezetek.
Minden ilyen eszköz rendelkezik alap hibakereső támogatással: le-, megállítással, léptetéssel, töréspontokkal, adatszerkezet-böngészéssel stb. A kereskedelmi eszközökben vannak nagyon pontos szimulátorok és nyomanelemzés, amik nem érhetők el nyílt forráskódú eszközökben.
Hasonló szabványok
A Serial Wire Debug (SWD) 2 tüskés elektromos felület azonos protokollal. A meglévő földelési csatlakozást használja. Az SWD ARM processzort használja kétirányú csatlakozóprotokollban, ARM Debug Interface v5 definíciója alapján.[15] Ez lehetővé teszi a hibakereső AMBA elsődleges busszá válását a rendszermemória és a periféria- vagy hibakereső-regiszterek hozzáférésében. Átviteli sebessége 4 MB/s 50 MHz-en. Az SWD-ben beépített hibakeresés is van. SWD-képes JTAG eszközökön a TMS és a TCK SWDIO és SWCLK jelek, duális módot lehetővé téve.
↑Oshana, Rob. „Introduction to JTAG”, Embedded Systems Design, 2002. október 29. (Hozzáférés: 2007. április 5.)
↑AN1817/D, "MMC20xx M•CORE OnCE Port Communication and Control Sequences"; Freescale Semiconductor, Inc.; 2004. Not all processors support the same OnCE module.
↑AN2073 "Differences Between the EOnCE and OnCE Ports"; Freescale Semiconductor, Inc.; 2005.
Ez a szócikk részben vagy egészben a JTAG című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.
