JTAG

Aby zapoznać się z modyfikacją sprzętu Xbox 360, zobacz Homebrew (gry wideo) § Xbox 360 .

JTAG (nazwany na cześć Joint Test Action Group , która go skodyfikowała) to branżowy standard weryfikacji projektów i testowania płytek drukowanych po wyprodukowaniu.

JTAG wdraża standardy oprzyrządowania na chipie w automatyzacji projektowania elektronicznego (EDA) jako narzędzie uzupełniające symulację cyfrową . Określa użycie dedykowanego portu debugowania implementującego interfejs komunikacji szeregowej w celu uzyskania dostępu o niskim narzucie bez konieczności bezpośredniego zewnętrznego dostępu do adresów systemowych i szyn danych. Interfejs łączy się z wbudowanym w układ testowym portem dostępu (TAP), który implementuje protokół stanowy w celu uzyskania dostępu do zestawu rejestrów testowych, które przedstawiają poziomy logiki układu i możliwości urządzeń różnych części.

Joint Test Action Group powstała w 1985 roku w celu opracowania metody weryfikacji projektów i testowania płytek drukowanych po wyprodukowaniu. W 1990 roku Instytut Inżynierów Elektryków i Elektroników skodyfikował wyniki prac w normie IEEE 1149.1-1990, zatytułowanej Standard Test Access Port and Boundary-Scan Architecture .

Standardy JTAG zostały rozszerzone przez wielu producentów układów półprzewodnikowych o wyspecjalizowane warianty, aby zapewnić funkcje specyficzne dla dostawcy.

Historia

W latach 80. wielowarstwowe płytki drukowane i układy scalone (IC) wykorzystujące siatkę kulową i podobne technologie montażu stały się standardem, a między układami scalonymi wykonywano połączenia, które nie były dostępne dla sond. Większość błędów produkcyjnych i eksploatacyjnych w płytkach drukowanych była spowodowana złymi lutowanymi na płytkach, niedoskonałościami połączeń między płytkami lub połączeniami i przewodami łączącymi płytki IC z ramkami wyprowadzeń pinów. Joint Test Action Group (JTAG) została utworzona w 1985 roku, aby zapewnić widok wyprowadzeń z jednej płytki IC do drugiej, aby można było wykryć te usterki.

Standard branżowy stał się standardem IEEE w 1990 roku jako IEEE Std. 1149.1-1990 po wielu latach początkowego użytkowania. W tym samym roku Intel wypuścił swój pierwszy procesor z JTAG ( 80486 ), co doprowadziło do szybszego przyjęcia go w branży przez wszystkich producentów. W 1994 r. dodatek zawierający opis języka opisu skanowania granic (BSDL) został dodany. Dalsze udoskonalenia dotyczące stosowania samych zer dla EXTEST, oddzielenia użycia SAMPLE od PRELOAD oraz lepszej implementacji dla komórek OBSERVE_ONLY zostały wprowadzone i wydane w 2001 roku. Od 1990 roku standard ten został przyjęty przez firmy elektroniczne na całym świecie . Skanowanie granic jest obecnie w większości synonimem JTAG, ale JTAG ma podstawowe zastosowania poza takimi zastosowaniami produkcyjnymi.

Debugowanie

Chociaż wczesne aplikacje JTAG były ukierunkowane na testowanie na poziomie płytki, tutaj standard JTAG został zaprojektowany, aby pomóc w testowaniu urządzeń, płyt i systemów, diagnostyce i izolacji błędów. Obecnie JTAG jest używany jako podstawowy sposób uzyskiwania dostępu do podbloków układów scalonych , co czyni go podstawowym mechanizmem debugowania systemów wbudowanych , które mogą nie mieć żadnego innego kanału komunikacyjnego obsługującego debugowanie. [ potrzebne źródło ] W większości systemów debugowanie oparte na JTAG jest dostępne od pierwszej instrukcji po resecie procesora, co pozwala na pomoc w opracowaniu oprogramowania wczesnego rozruchu, które działa przed skonfigurowaniem czegokolwiek. Emulator w obwodzie (lub bardziej poprawnie, „adapter JTAG”) wykorzystuje JTAG jako mechanizm transportowy w celu uzyskania dostępu do wbudowanych modułów debugowania wewnątrz docelowego procesora . Moduły te pozwalają programistom debugować oprogramowanie systemu wbudowanego bezpośrednio na poziomie instrukcji maszynowych, gdy jest to potrzebne, lub (częściej) w zakresie kodu źródłowego języka wysokiego poziomu.

Obsługa debugowania oprogramowania systemowego jest dla wielu twórców oprogramowania głównym powodem zainteresowania JTAG. Wiele architektur krzemowych, takich jak PowerPC, MIPS, ARM i x86, zbudowało całą infrastrukturę debugowania oprogramowania, śledzenia instrukcji i śledzenia danych wokół podstawowego protokołu JTAG. Jednak często indywidualni dostawcy krzemu wdrażają tylko części tych rozszerzeń. Niektóre przykłady to ARM CoreSight i Nexus a także implementacje BTS (Branch Trace Storage), LBR (ostatni rekord oddziału) i IPT (Intel Processor Trace) firmy Intel. Istnieje wiele innych takich rozszerzeń specyficznych dla dostawców krzemu, które mogą nie być udokumentowane, z wyjątkiem NDA . Przyjęcie standardu JTAG pomogło odsunąć środowiska debugowania skoncentrowane na JTAG od wczesnych projektów specyficznych dla procesorów. Procesory można normalnie zatrzymać, wykonać krok po kroku lub pozwolić im działać swobodnie. Można ustawić punkty przerwania kodu, zarówno dla kodu w pamięci RAM (często przy użyciu specjalnej instrukcji maszynowej), jak iw pamięci ROM/flash. Często dostępne są punkty przerwania danych, podobnie jak masowe pobieranie danych do pamięci RAM. Większość projektów ma „debugowanie w trybie zatrzymania”, ale niektóre umożliwiają debugerom dostęp do rejestrów i szyn danych bez konieczności zatrzymywania debugowanego rdzenia. Niektóre łańcuchy narzędzi mogą wykorzystywać moduły ARM Embedded Trace Macrocell (ETM) lub równoważne implementacje w innych architekturach do wyzwalania działania debuggera (lub śledzenia) w przypadku złożonych zdarzeń sprzętowych, takich jak analizator stanów logicznych zaprogramowany do ignorowania pierwszych siedmiu wejść do rejestru z jednego określonego podprogramu.

Czasami programiści FPGA używają również JTAG do opracowywania narzędzi do debugowania. Te same techniki JTAG używane do debugowania oprogramowania działającego wewnątrz procesora mogą pomóc w debugowaniu innych cyfrowych bloków projektowych wewnątrz FPGA. Na przykład można dostarczyć niestandardowe instrukcje JTAG, aby umożliwić odczytywanie rejestrów zbudowanych z dowolnych zestawów sygnałów wewnątrz FPGA, zapewniając widoczność zachowań, które są niewidoczne dla operacji skanowania granic. Podobnie pisanie takich rejestrów mogłoby zapewnić sterowalność, która nie jest dostępna w inny sposób.

Przechowywanie oprogramowania układowego

JTAG umożliwia sprzętowemu programatorowi urządzeń przesyłanie danych do wewnętrznej nieulotnej pamięci urządzenia (np. CPLD ). Niektórzy programiści urządzeń służą dwóm celom: programowaniu i debugowaniu urządzenia. W przypadku FPGA urządzenia z pamięcią ulotną można również programować przez port JTAG, zwykle podczas prac rozwojowych. Ponadto wewnętrzne możliwości monitorowania (temperatura, napięcie i prąd) mogą być dostępne za pośrednictwem portu JTAG.

Programatory JTAG są również wykorzystywane do zapisywania oprogramowania i danych w pamięci flash . Zwykle odbywa się to przy użyciu tego samego dostępu do magistrali danych, z którego korzystałby procesor, i czasami jest obsługiwane przez procesor. W innych przypadkach same układy pamięci mają interfejsy JTAG. Niektóre nowoczesne architektury debugowania zapewniają wewnętrzny i zewnętrzny dostęp do mastera magistrali bez konieczności zatrzymywania i przejmowania procesora. W najgorszym przypadku zwykle możliwe jest sterowanie sygnałami magistrali zewnętrznej za pomocą funkcji skanowania granic.

Z praktycznego punktu widzenia podczas opracowywania systemu wbudowanego emulacja magazynu instrukcji jest najszybszym sposobem wdrożenia „cyklu debugowania” (edycja, kompilacja, pobieranie, testowanie i debugowanie). [ Potrzebne źródło ] Dzieje się tak, ponieważ emulator w obwodzie symulujący magazyn instrukcji można bardzo szybko zaktualizować z hosta programistycznego przez, powiedzmy, USB. Używanie portu szeregowego UART i programu ładującego do przesyłania oprogramowania układowego do Flasha sprawia, że ​​ten cykl debugowania jest dość powolny i prawdopodobnie kosztowny pod względem narzędzi; instalowanie oprogramowania układowego we Flashu (lub SRAM zamiast Flasha) przez JTAG jest rozwiązaniem pośrednim między tymi skrajnościami.

Testowanie skanowania granic

skanowania granic JTAG zapewnia dostęp do wielu sygnałów logicznych złożonego układu scalonego, w tym do pinów urządzenia. Sygnały są reprezentowane w rejestrze skanowania granic (BSR) dostępnym przez TAP. Pozwala to na testowanie, jak również kontrolowanie stanów sygnałów do testowania i debugowania. Dzięki temu możliwe jest lokalizowanie błędów zarówno programowych, jak i sprzętowych (produkcyjnych) oraz monitorowanie działającego urządzenia.

W połączeniu z wbudowanym autotestem ( BIST ), łańcuch skanowania JTAG umożliwia niskonakładowe, wbudowane rozwiązanie do testowania układu scalonego pod kątem pewnych błędów statycznych (zwarcia, przerwy i błędy logiczne). Mechanizm łańcucha skanowania zasadniczo nie pomaga w diagnozowaniu lub testowaniu synchronizacji, temperatury lub innych dynamicznych błędów operacyjnych, które mogą wystąpić. Przypadki testowe są często dostarczane w znormalizowanych formatach, takich jak SVF lub jego binarny odpowiednik XSVF, i są używane w testach produkcyjnych. Możliwość przeprowadzania takich testów na gotowych płytach jest istotną częścią Design For Test w dzisiejszych produktach, zwiększając liczbę usterek, które można wykryć, zanim produkty zostaną wysłane do klientów.

Parametry elektryczne

Interfejs JTAG to specjalny interfejs dodawany do chipa. W zależności od wersji JTAG dodaje się dwa, cztery lub pięć pinów. Cztero- i pięciopinowe interfejsy są zaprojektowane tak, aby wiele chipów na płytce mogło mieć łańcuchowo linie JTAG , jeśli zostaną spełnione określone warunki. Dwupinowy interfejs został zaprojektowany tak, aby można było połączyć wiele chipów w topologii gwiazdy . W obu przypadkach sonda testowa musi być podłączona tylko do jednego „portu JTAG”, aby mieć dostęp do wszystkich układów scalonych na płytce drukowanej .

Połączone łańcuchowo JTAG (IEEE 1149.1)

Example of JTAG chain. Test reset signal is not shown

Piny złącza to:

  1. TDI (dane testowe w)
  2. TDO (wyjście danych testowych)
  3. TCK (zegar testowy)
  4. TMS (wybór trybu testowego)
  5. TRST (reset testowy) opcjonalnie.

Pin TRST jest opcjonalnym aktywnym-niskim resetem do logiki testowej, zwykle asynchronicznym, ale czasami synchronicznym, w zależności od układu. Jeśli pin nie jest dostępny, logikę testu można zresetować, przełączając się synchronicznie do stanu resetowania za pomocą TCK i TMS. Pamiętaj, że resetowanie logiki testowej niekoniecznie oznacza resetowanie czegokolwiek innego. Na ogół istnieją pewne operacje JTAG specyficzne dla procesora, które mogą zresetować całość lub część debugowanego układu.

Ponieważ dostępna jest tylko jedna linia danych, protokół jest szeregowy . Wejście zegara znajduje się na pinie TCK. Jeden bit danych jest przesyłany z TDI i na zewnątrz do TDO na narastające zbocze zegara TCK. Można załadować różne instrukcje. Instrukcje dla typowych układów scalonych mogą odczytywać identyfikator chipa, przykładać piny wejściowe, piny wyjściowe sterujące (lub pływakowe), manipulować funkcjami chipa lub obejść (potokować TDI do TDO, aby logicznie skrócić łańcuchy wielu chipów).

Podobnie jak w przypadku każdego taktowanego sygnału, dane prezentowane w TDI muszą być ważne przez określony czas konfiguracji układu przed i czas wstrzymania po odpowiednim (tutaj narastającym) zboczu zegara. Dane TDO są ważne przez pewien czas specyficzny dla chipa po opadającym zboczu TCK.

Maksymalna częstotliwość robocza TCK różni się w zależności od wszystkich chipów w łańcuchu (należy zastosować najniższą prędkość), ale zwykle wynosi 10-100 MHz (100-10 ns na bit). Również częstotliwości TCK zależą od układu płytki oraz możliwości i stanu adaptera JTAG. Jeden układ może mieć zegar JTAG 40 MHz, ale tylko wtedy, gdy używa zegara 200 MHz do operacji innych niż JTAG; i może wymagać użycia znacznie wolniejszego zegara, gdy jest w trybie niskiego zużycia energii. W związku z tym niektóre adaptery JTAG mają adaptacyjne taktowanie z wykorzystaniem sygnału RTCK (Return TCK). Szybsze częstotliwości TCK są najbardziej przydatne, gdy JTAG jest używany do przesyłania dużej ilości danych, na przykład podczas przechowywania programu wykonywalnego w pamięć flash .

Zegarowanie zmian w krokach TMS za pomocą znormalizowanej maszyny stanu JTAG . Maszyna stanu JTAG może zresetować, uzyskać dostęp do rejestru instrukcji lub uzyskać dostęp do danych wybranych przez rejestr instrukcji.

Platformy JTAG często dodają sygnały do ​​garstki określonej przez specyfikację IEEE 1149.1. Sygnał resetowania systemu (SRST) jest dość powszechny, pozwalając debuggerom zresetować cały system, a nie tylko części z obsługą JTAG. Czasami istnieją sygnały zdarzeń używane do wyzwalania aktywności przez hosta lub urządzenie monitorowane przez JTAG; lub być może dodatkowe linie kontrolne.

Chociaż niewiele produktów konsumenckich zapewnia wyraźne złącze portu JTAG, połączenia są często dostępne na płytce drukowanej jako pozostałość po opracowywaniu prototypów i / lub produkcji. Kiedy są wykorzystywane, połączenia te często zapewniają najbardziej opłacalne środki inżynierii odwrotnej .

Zmniejszona liczba pinów JTAG (IEEE 1149.7)

Przykład JTAG ze zmniejszoną liczbą pinów

Zmniejszona liczba pinów JTAG wykorzystuje tylko dwa przewody, przewód zegara i przewód danych. Jest to zdefiniowane jako część standardu IEEE 1149.7. Piny złącza to:

  1. TMSC (testowe dane seryjne)
  2. TCK (zegar testowy)

Nazywa się cJTAG od kompaktowego JTAG.

Dwuprzewodowy interfejs zmniejszył nacisk na liczbę styków, a urządzenia można łączyć w topologii gwiazdy . Topologia gwiazdy umożliwia wyłączenie niektórych części systemu, podczas gdy dostęp do innych można nadal uzyskać za pośrednictwem JTAG; połączenie łańcuchowe wymaga zasilania wszystkich interfejsów JTAG. Istnieją inne interfejsy dwuprzewodowe, takie jak Serial Wire Debug .

Model komunikacji

W JTAG urządzenia udostępniają jeden lub więcej testowych portów dostępu (TAP). Powyższy rysunek pokazuje trzy TAP-y, które mogą być pojedynczymi chipami lub modułami wewnątrz jednego chipa. Łańcuch stokrotek TAP nazywany jest łańcuchem skanowania lub (luźno) celem. Łańcuchy skanowania mogą być dowolnie długie, ale w praktyce dwadzieścia TAP-ów to niezwykle długo. [ potrzebne źródło ]

Aby użyć JTAG, host jest podłączony do sygnałów JTAG celu (TMS, TCK, TDI, TDO, itp.) za pośrednictwem pewnego rodzaju adaptera JTAG , który może wymagać obsługi problemów, takich jak przesunięcie poziomu i izolacja galwaniczna . Adapter łączy się z hostem za pomocą interfejsu, takiego jak USB, PCI, Ethernet i tak dalej.

prymitywy

Host komunikuje się z TAPami, manipulując TMS i TDI w połączeniu z TCK oraz odczytując wyniki przez TDO (który jest jedynym standardowym wejściem po stronie hosta). Przejścia wyjściowe TMS/TDI/TCK tworzą podstawowy prymityw komunikacyjny JTAG, na którym zbudowane są protokoły wyższych warstw:

  • Przełączanie stanu ... Wszystkie TAP są w tym samym stanie, a stan ten zmienia się przy przejściach TCK. Ta maszyna stanów JTAG jest częścią specyfikacji JTAG i obejmuje szesnaście stanów. Istnieje sześć „stanów stabilnych”, w których utrzymywanie stabilności TMS zapobiega zmianie stanu. We wszystkich innych stanach TCK zawsze zmienia ten stan. Ponadto potwierdzenie TRST wymusza wejście do jednego z tych stabilnych stanów (Test_Logic_Reset) w nieco szybszy sposób niż alternatywa polegająca na utrzymaniu TMS na wysokim poziomie i pięciokrotnym cyklu TCK.
  • Przesuwanie ... Większość części maszyny stanowej JTAG obsługuje dwa stabilne stany używane do przesyłania danych. Każdy TAP ma rejestr instrukcji (IR) i rejestr danych (DR). Rozmiar tych rejestrów różni się w zależności od TAP, a rejestry te są łączone przez TDI i TDO, tworząc duży rejestr przesuwny. (Rozmiar DR jest funkcją wartości w bieżącym IR tego TAP-a i ewentualnie wartości określonej przez instrukcję SCAN_N.) W tym rejestrze przesuwnym zdefiniowano trzy operacje:
    • Przechwytywanie wartości tymczasowej
      • Wejście do stabilnego stanu Shift_IR przechodzi przez stan Capture_IR, ładując do rejestru przesuwnego częściowo ustaloną wartość (nie bieżącą instrukcję)
      • Wejście do stabilnego stanu Shift_DR odbywa się poprzez stan Capture_DR, ładując wartość Rejestru Danych określoną przez aktualny IR TAP.
    • Przesuwanie tej wartości bit po bicie, w stanie stabilnym Shift_IR lub Shift_DR; Przejścia TCK przesuwają rejestr przesuwny o jeden bit, z TDI w kierunku TDO, dokładnie tak, jak SPI 1 przez łańcuch urządzeń (z TMS=0 działającym jak sygnał wyboru chipa, TDI jako MOSI itp.).
    • Aktualizacja IR lub DR z przesuniętej wartości tymczasowej przy przejściu przez stan Update_IR lub Update_DR. Należy zauważyć, że nie jest możliwe odczytanie (przechwycenie) rejestru bez jego zapisania (aktualizacji) i odwrotnie. Powszechny idiom dodaje bity flagi, aby powiedzieć, czy aktualizacja powinna mieć skutki uboczne lub czy sprzęt jest gotowy do wykonania takich skutków ubocznych.
  • Running ... Jeden stabilny stan nazywa się Run_Test/Idle. To rozróżnienie jest specyficzne dla TAP. Taktowanie TCK w stanie bezczynności nie ma szczególnych skutków ubocznych, ale taktowanie go w stanie Run_Test może zmienić stan systemu. Na przykład niektóre ARM9 obsługują tryb debugowania, w którym cykle TCK w stanie Run_Test kierują potokiem instrukcji.

Na poziomie podstawowym korzystanie z JTAG obejmuje odczytywanie i zapisywanie instrukcji oraz związanych z nimi rejestrów danych; a czasami wymaga przeprowadzenia kilku cykli testowych. Za tymi rejestrami znajduje się sprzęt, który nie jest określony przez JTAG i który ma swoje własne stany, na które wpływają działania JTAG.

Większość hostów JTAG używa najkrótszej ścieżki między dwoma stanami, być może ograniczonej dziwactwami adaptera. (Na przykład jeden adapter [ który? ] obsługuje tylko ścieżki, których długość jest wielokrotnością siedmiu bitów.) Niektóre warstwy zbudowane na JTAG monitorują przejścia stanów i używają nietypowych ścieżek do wyzwalania operacji wyższego poziomu. Niektóre rdzenie ARM używają takich sekwencji do wchodzenia i wychodzenia z dwuprzewodowego (nie-JTAG) trybu SWD . Sekwencja Zero Bit Scan (ZBS) jest używana w IEEE 1149.7 w celu uzyskania dostępu do zaawansowanych funkcji, takich jak przełączanie TAP do i z łańcuchów skanowania, zarządzanie energią i inny tryb dwuprzewodowy.

Instrukcje JTAG IEEE Std 1149.1 (skanowanie granic).

Rozmiary rejestrów instrukcji są zwykle małe, być może mają szerokość czterech lub siedmiu bitów. Z wyjątkiem BYPASS i EXTEST, wszystkie kody operacji instrukcji są definiowane przez realizatora TAP, podobnie jak powiązane z nimi rejestry danych; nie należy używać niezdefiniowanych kodów instrukcji. Dwie kluczowe instrukcje to:

  • Instrukcja BYPASS, kod operacji wszystkich jedynek, niezależnie od rozmiaru rejestru instrukcji TAP, musi być obsługiwana przez wszystkie TAP-y. Instrukcja wybiera jednobitowy rejestr danych (zwany także BYPASS). Instrukcja pozwala na ominięcie tego urządzenia (nie rób nic), podczas gdy inne urządzenia w ścieżce skanowania są wykonywane.
  • Opcjonalna instrukcja IDCODE z kodem operacyjnym zdefiniowanym przez implementatora. IDCODE jest powiązany z 32-bitowym rejestrem (IDCODE). Jego dane mają znormalizowany format, który obejmuje kod producenta (pochodzący ze standardowego kodu identyfikacyjnego producenta JEDEC , JEP-106), numer części przypisany przez producenta oraz kod wersji części. IDCODE jest szeroko, ale nie powszechnie obsługiwany.

Przy wyjściu ze stanu RESET, rejestr instrukcji jest wstępnie ładowany z BYPASS lub IDCODE. Pozwala to hostom JTAG zidentyfikować rozmiar i przynajmniej częściowo zawartość łańcucha skanowania, do którego są podłączone. (Mogą wejść w stan RESET, a następnie skanować rejestr danych, dopóki nie odczytają zapisanych danych. Rejestr BYPASS ma tylko bit zerowy, podczas gdy rejestr IDCODE ma 32 bity i zaczyna się od jedynki. Więc bity nie zapisywane przez hosta można łatwo zmapować do TAP.) Taka identyfikacja jest często używana do sprawdzania poprawności ręcznej konfiguracji, ponieważ IDCODE jest często niespecyficzny. Może na przykład zidentyfikować mikrokontroler oparty na ARM Cortex-M3, bez określania dostawcy lub modelu mikrokontrolera; lub konkretny układ FPGA, ale nie sposób, w jaki został zaprogramowany.

Powszechny idiom polega na przesunięciu BYPASS do rejestrów instrukcji wszystkich TAP-ów z wyjątkiem jednego, który otrzymuje inną instrukcję. W ten sposób wszystkie TAP, z wyjątkiem jednego, udostępniają rejestr danych jednobitowych, a wartości mogą być selektywnie przesuwane do lub z rejestru danych tego jednego TAP bez wpływu na inne TAP.

Standard IEEE 1149.1 (JTAG) opisuje szereg instrukcji obsługujących aplikacje skanowania granic. Niektóre z tych instrukcji są „obowiązkowe”, ale TAP używane do debugowania zamiast testowania skanowania granic czasami zapewniają minimalne lub żadne wsparcie dla tych instrukcji. Te „obowiązkowe” instrukcje działają na Boundary Scan Register (BSR) zdefiniowanym w BSDL i obejmują:

  • EXTEST do testów zewnętrznych, takich jak używanie pinów do sondowania zachowań na poziomie płytki
  • PRELOAD ładuje wartości wyjściowe pinów przed EXTEST (czasami w połączeniu z PRÓBKĄ)
  • SAMPLE wczytuje wartości pinów do rejestru skanowania granicy

Zdefiniowane przez IEEE „Opcjonalne” instrukcje obejmują:

  • CLAMP wariant BYPASS, który steruje pinami wyjściowymi przy użyciu wartości PRELOADed
  • HIGHZ dezaktywuje wyjścia wszystkich pinów
  • INTEST do testów wewnętrznych, takich jak używanie pinów do sondowania zachowań na chipie
  • RUNBIST umieszcza chip w trybie autotestu
  • USERCODE zwraca kod zdefiniowany przez użytkownika, na przykład w celu określenia, który obraz FPGA jest aktywny

Urządzenia mogą definiować więcej instrukcji, a definicje te powinny być częścią pliku BSDL dostarczonego przez producenta. Często są one oznaczone tylko jako PRYWATNE.

Rejestr skanowania granic

Urządzenia komunikują się ze światem za pomocą zestawu pinów wejściowych i wyjściowych. Te kołki same w sobie zapewniają ograniczoną widoczność działania urządzenia. Jednak urządzenia obsługujące skanowanie granic zawierają komórkę rejestru przesuwnego dla każdego pinu sygnałowego urządzenia. Rejestry te są połączone w dedykowaną ścieżkę wokół granicy urządzenia (stąd nazwa). Ścieżka tworzy możliwość wirtualnego dostępu, która omija normalne wejścia i wyjścia, zapewniając bezpośrednią kontrolę nad urządzeniem i szczegółową widoczność sygnałów.

Zawartość rejestru skanowania granic, w tym możliwości sygnału we/wy, jest zwykle opisana przez producenta przy użyciu pliku BSDL specyficznego dla części . Są one używane z projektowymi „listami sieci” z systemów CAD/EDA do opracowywania testów stosowanych w produkcji płytek. Komercyjne systemy testowe często kosztują kilka tysięcy dolarów za kompletny system i zawierają opcje diagnostyczne umożliwiające zlokalizowanie usterek, takich jak otwarte obwody i zwarcia. Mogą również oferować przeglądarki schematów lub układów, aby przedstawić usterkę w sposób graficzny.

Aby umożliwić skanowanie granic, dostawcy układów scalonych dodają logikę do każdego ze swoich urządzeń, w tym komórki skanujące dla każdego z pinów sygnałowych. Komórki te są następnie łączone ze sobą, tworząc rejestr przesuwny skanowania granic (BSR), który jest podłączony do kontrolera TAP. Te projekty są częścią większości bibliotek Verilog lub VHDL. Narzut związany z tą dodatkową logiką jest minimalny i generalnie jest wart swojej ceny, aby umożliwić wydajne testowanie na poziomie płytki.

Przykład: TAP debugowania ARM11

Przykład pomaga pokazać działanie JTAG w rzeczywistych układach. Przykładem jest TAP debugowania ARM11 , rdzeń ARM1136. Sam procesor ma szerokie możliwości JTAG, podobne do tych, które można znaleźć w innych rdzeniach procesora, i jest zintegrowany z układami scalonymi z jeszcze bardziej rozbudowanymi możliwościami, do których można uzyskać dostęp za pośrednictwem JTAG.

Jest to nietrywialny przykład, który jest reprezentatywny dla znacznej części systemów obsługujących JTAG. Ponadto pokazuje, w jaki sposób mechanizmy kontrolne są budowane przy użyciu prymitywów odczytu/zapisu rejestrów JTAG i jak te elementy łączą się, aby ułatwić testowanie i debugowanie złożonych elementów logicznych; Procesory są powszechne, ale układy FPGA i ASIC zawierają inne złożone elementy, które należy debugować.

Licencjobiorcy tego rdzenia integrują go z układami scalonymi, zwykle łącząc go z innymi TAP-ami oraz licznymi urządzeniami peryferyjnymi i pamięcią. Jeden z tych innych TAPów obsługuje testy skanowania granic dla całego układu; nie jest obsługiwany przez TAP debugowania. Przykładami takich chipów są:

  • OMAP2420 , który zawiera TAP skanowania granic, TAP debugowania ARM1136, TAP bufora śledzenia ETB11, C55x DSP i TAP dla silnika obrazowania opartego na ARM7 TDMI, przy czym TAP skanowania granic („ICEpick-B”) ma możliwość łączenia TAP-ów z łańcuchem skanowania JTAG iz niego.
  • Procesor i.MX31 , który jest podobny, chociaż jego TAP skanowania granic „System JTAG”, który bardzo różni się od ICEpick, i zawiera TAP dla swojego silnika DMA zamiast DSP i silnika obrazowania.

Oba te procesory są przeznaczone do użytku w telefonach bezprzewodowych, takich jak telefony komórkowe, co jest jednym z powodów, dla których zawierają kontrolery TAP, które modyfikują łańcuch skanowania JTAG: Debugowanie operacji o niskim poborze mocy wymaga dostępu do chipów, gdy są one w dużej mierze wyłączone, a zatem kiedy nie wszystkie TAPy działają. Ta modyfikacja łańcucha skanowania jest jednym z tematów nadchodzącej normy IEEE 1149.7.

Wyposażenie JTAG

Ten TAP debugowania udostępnia kilka standardowych instrukcji i kilka specjalnie zaprojektowanych do debugowania wspomaganego sprzętowo , w którym narzędzie programowe („debugger”) używa JTAG do komunikacji z debugowanym systemem:

  • BYPASS i IDCODE , standardowe instrukcje opisane powyżej
  • EXTEST , INTEST , standardowe instrukcje, ale działające na rdzeniu zamiast zewnętrznego łańcucha skanowania granic. EXTEST jest nominalnie do zapisu danych do rdzenia, INTEST jest nominalnie do ich odczytu; ale dwa łańcuchy skanowania są wyjątkami od tej reguły.
  • SCAN_N Instrukcja ARM do wyboru numerowanego łańcucha skanowania używanego z EXTEST lub INTEST . Istnieje sześć łańcuchów skanowania:
    • 0- Rejestr ID urządzenia, 40 bitów danych identyfikacyjnych tylko do odczytu
    • 1 - Debug Status and Control Register (DSCR), 32 bity używane do obsługi funkcji debugowania
    • 4 - Rejestr transferu instrukcji (ITR), 33 bity (32 instrukcje plus jeden bit stanu) używane do wykonywania instrukcji procesora w specjalnym „trybie debugowania” (patrz poniżej)
    • 5 - Debug Communications Channel (DCC), 34 bity (jedno długie słowo danych plus dwa bity stanu) używane do dwukierunkowego przesyłania danych do rdzenia. Jest to używane zarówno w trybie debugowania, jak i prawdopodobnie w czasie wykonywania podczas komunikacji z oprogramowaniem obsługującym debugger.
    • 6 - Wbudowany moduł śledzenia (ETM), 40 bitów (7-bitowy adres, jedno 32-bitowe słowo danych i bit R/W) używany do sterowania działaniem pasywnej instrukcji i mechanizmu śledzenia danych. To zasila wbudowany w układ wbudowany bufor śledzenia (ETB) lub zewnętrzny moduł zbierania danych o dużej szybkości. Śledzenie obsługuje pasywne debugowanie (badanie historii wykonywania) i profilowanie w celu dostrajania wydajności.
    • 7 - moduł debugowania, 40 bitów (7-bitowy adres, jedno 32-bitowe słowo danych i bit R/W) używane do uzyskiwania dostępu do sprzętowych punktów przerwania, punktów obserwacyjnych i innych. Można je zapisywać podczas pracy procesora; nie musi być w trybie debugowania.
  • HALT i RESTART , instrukcje specyficzne dla ARM11, aby zatrzymać i ponownie uruchomić procesor. Zatrzymanie go wprowadza rdzeń w „tryb debugowania”, w którym ITR może być używany do wykonywania instrukcji, w tym za pomocą DCC do przesyłania danych między hostem debugowania (JTAG) a procesorem.
  • ITRSEL , instrukcja specyficzna dla ARM11, aby przyspieszyć niektóre operacje z ITR.

Model ten przypomina model stosowany w innych rdzeniach ARM. Systemy inne niż ARM mają na ogół podobne możliwości, być może zaimplementowane przy użyciu Nexus na szczycie JTAG lub innych schematów specyficznych dla dostawcy.

Starsze rdzenie ARM7 i ARM9 zawierają moduł EmbeddedICE , który łączy większość tych funkcji, ale ma niewygodny mechanizm wykonywania instrukcji: debugger musi sterować potokiem instrukcji procesora, zegar po zegarze i bezpośrednio uzyskiwać dostęp do szyn danych, aby odczytywać i zapisywać dane do procesor. ARM11 wykorzystuje ten sam model obsługi śledzenia (ETM, ETB), co starsze rdzenie.

Nowsze rdzenie ARM Cortex bardzo przypominają ten model debugowania, ale opierają się na porcie dostępu do debugowania (DAP) zamiast bezpośredniego dostępu do procesora. W tej architekturze (o nazwie CoreSight Technology ) rdzeń i moduł JTAG są całkowicie niezależne. Są również oddzielone od JTAG, dzięki czemu mogą być hostowane przez dwuprzewodowy SWD ARM interfejs (patrz poniżej) zamiast tylko sześcioprzewodowego interfejsu JTAG. (ARM bierze cztery standardowe sygnały JTAG i dodaje opcjonalny TRST oraz sygnał RTCK używany do adaptacyjnego taktowania.) CoreSight JTAG-DP jest asynchroniczny z zegarami rdzenia i nie implementuje RTCK. Ponadto nowsze rdzenie mają zaktualizowaną obsługę śledzenia.

Debugowanie w trybie zatrzymania

Jednym z podstawowych sposobów debugowania oprogramowania jest przedstawienie modelu jednowątkowego, w którym debugger okresowo zatrzymuje wykonywanie programu i sprawdza jego stan ujawniony przez zawartość rejestrów i pamięć (w tym rejestry kontrolerów peryferyjnych). Kiedy zbliżają się interesujące wydarzenia programowe, osoba może chcieć wykonać jednoetapowe instrukcje (lub wiersze kodu źródłowego), aby zobaczyć, jak dzieje się określone niewłaściwe zachowanie.

Na przykład host JTAG może ZATRZYMAĆ rdzeń, wejść w tryb debugowania, a następnie odczytać rejestry procesora za pomocą ITR i DCC. Po zapisaniu stanu procesora może zapisać te rejestry z dowolnymi wartościami, których potrzebuje, a następnie wykonać dowolne algorytmy na procesorze, uzyskując dostęp do pamięci i urządzeń peryferyjnych, aby pomóc scharakteryzować stan systemu. Po wykonaniu tych operacji przez debugger można przywrócić stan i kontynuować wykonywanie za pomocą instrukcji RESTART.

Tryb debugowania jest również wprowadzany asynchronicznie przez moduł debugowania wyzwalający punkt kontrolny lub punkt przerwania lub przez wydanie instrukcji BKPT (punkt przerwania) z debugowanego oprogramowania. Gdy nie jest używany do śledzenia instrukcji, ETM może również wywołać wejście w tryb debugowania; obsługuje złożone wyzwalacze wrażliwe na stan i historię, a także proste porównania adresów ujawniane przez moduł debugowania. Asynchroniczne przejścia do trybu debugowania są wykrywane przez odpytywanie rejestru DSCR. W ten sposób realizowane są pojedyncze kroki: ZATRZYMAJ rdzeń, ustaw tymczasowy punkt przerwania przy następnej instrukcji lub następnej instrukcji wysokiego poziomu, RESTART, odpytuj DSCR, aż wykryjesz asynchroniczne wejście do stanu debugowania, usuń ten tymczasowy punkt przerwania, powtórz.

Debugowanie w trybie monitorowania

Nowoczesne oprogramowanie jest często zbyt skomplikowane, aby dobrze działać z takim jednowątkowym modelem. Na przykład procesor używany do sterowania silnikiem (być może napędzającym brzeszczot piły) może nie być w stanie bezpiecznie przejść w tryb zatrzymania; może być konieczne kontynuowanie obsługi przerwań w celu zapewnienia fizycznego bezpieczeństwa ludzi i/lub maszyn. Wydanie instrukcji HALT za pomocą JTAG może być niebezpieczne.

Procesory ARM obsługują alternatywny tryb debugowania, zwany trybem monitorowania , do pracy w takich sytuacjach. (Różni się to od trybu bezpiecznego monitorowania zaimplementowanego jako część rozszerzeń zabezpieczeń na nowszych rdzeniach ARM; zarządza operacjami debugowania, a nie przejściami zabezpieczeń). W takich przypadkach punkty przerwania i punkty kontrolne wyzwalają specjalny rodzaj wyjątku sprzętowego, przekazując kontrolę do „ monitor debugowania” działający jako część oprogramowania systemowego. Ten monitor komunikuje się z debugerem za pomocą DCC i może na przykład zaaranżować wykonanie pojedynczego kroku tylko jednego procesu, podczas gdy inne procesy (i procedury obsługi przerwań) kontynuują działanie.

Wspólne rozszerzenia

Dostawcy mikroprocesorów często definiowali własne rozszerzenia debugowania specyficzne dla rdzenia. Tacy dostawcy to Infineon , MIPS z EJTAG i inni. Jeśli dostawca nie przyjmuje standardu (takiego jak ten używany przez procesory ARM lub Nexus), musi zdefiniować własne rozwiązanie. Jeśli obsługują skanowanie granic, generalnie budują debugowanie na JTAG.

Freescale ma COP i OnCE (emulacja na chipie). OnCE zawiera polecenie JTAG, które sprawia, że ​​TAP wchodzi w specjalny tryb, w którym IR przechowuje polecenia debugowania OnCE dla operacji, takich jak wykonywanie pojedynczych kroków, wyznaczanie punktów przerwania i dostęp do rejestrów lub pamięci. Definiuje również EOnCE (Enhanced On-Chip Emulation) przedstawioną jako rozwiązującą problemy w czasie rzeczywistym.

ARM ma rozbudowaną architekturę debugowania rdzeni procesora (CoreSight), która rozpoczęła się od EmbeddedICE (funkcja debugowania dostępna w większości rdzeni ARM), a teraz obejmuje wiele dodatkowych komponentów, takich jak ETM (Embedded Trace Macrocell), z szybkim portem śledzenia, obsługującym śledzenie wielordzeniowe i wielowątkowe. Należy pamiętać, że śledzenie jest nieinwazyjne; systemy nie muszą przestać działać, aby można je było śledzić. (Jednak dane śledzenia są zbyt obszerne, aby używać JTAG jako czegoś więcej niż kanału sterowania śledzeniem).

Nexus definiuje infrastrukturę debugowania procesora, która jest w dużej mierze niezależna od dostawcy. Jednym z jego interfejsów sprzętowych jest JTAG. Definiuje również szybki interfejs portu pomocniczego, używany do śledzenia i nie tylko. Nexus jest używany z niektórymi nowszymi platformami, takimi jak Atmel AVR32 i Freescale MPC5500.

Używa

  • Z wyjątkiem niektórych z najniższych systemów końcowych, zasadniczo wszystkie platformy systemów wbudowanych mają port JTAG do obsługi debugowania w obwodzie i programowania oprogramowania układowego, a także do testowania skanowania granic:
  • Standard złącza magistrali PCI zawiera opcjonalne sygnały JTAG na stykach 1–5; PCI Express zawiera sygnały JTAG na pinach 5–9. Specjalna karta JTAG może być użyta do flashowania uszkodzonego BIOS-u .
  • Testowanie skanowania granic i aplikacje do programowania w systemie (urządzeniu) są czasami programowane przy użyciu formatu wektora szeregowego , tekstowej reprezentacji operacji JTAG przy użyciu prostej składni. Inne formaty programowania obejmują „JAM” i STAPL, a ostatnio IEEE Std. 1532 zdefiniowany format „ISC” (skrót od In-System Configuration). Format ISC jest używany w połączeniu z rozszerzonymi modelami BSDL dla programowalnych urządzeń logicznych (tj. FPGA i CPLD), które zawierają dodatkowe instrukcje ISC_<operacja> oprócz podstawowych instrukcji IEEE 1149.1. Narzędzia programistyczne FPGA firmy Xilinx , Altera, Lattice, Cypress, Atel itp. zazwyczaj są w stanie wyeksportować takie pliki.
  • Jak wspomniano, wiele płyt zawiera złącza JTAG lub po prostu pady, które wspierają operacje produkcyjne, gdzie testy skanowania granicznego pomagają zweryfikować jakość płytki (identyfikacja złych połączeń lutowniczych itp.) oraz zainicjować pamięć flash lub układy FPGA.
  • JTAG może również wspierać aktualizacje w terenie i rozwiązywanie problemów.

Wsparcie klienta

Interfejs JTAG celu jest dostępny za pomocą niektórych aplikacji obsługujących JTAG i niektórych sprzętowych adapterów JTAG. Istnieje szeroka gama takiego sprzętu, zoptymalizowanego do celów takich jak testowanie produkcji, debugowanie szybkich systemów, rozwój tanich mikrokontrolerów i tak dalej. W ten sam sposób oprogramowanie używane do obsługi takiego sprzętu może być bardzo zróżnicowane. Twórcy oprogramowania najczęściej używają JTAG do debugowania i aktualizacji oprogramowania układowego.

Złącza

Zapora ogniowa Netgear FVS336G z 14 - pinowym nagłówkiem JTAG w lewym dolnym rogu.
Netgear DG632 ADSL z 8-pinowym nagłówkiem JTAG w lokalizacji „5”.

Nie ma oficjalnych norm dotyczących fizycznych złączy adaptera JTAG. Płytki rozwojowe zwykle zawierają nagłówek obsługujący preferowane narzędzia programistyczne; w niektórych przypadkach zawierają wiele takich nagłówków, ponieważ muszą obsługiwać wiele takich narzędzi. Na przykład mikrokontroler, FPGA i procesor aplikacyjny ARM rzadko współdzielą narzędzia, więc płyta rozwojowa wykorzystująca wszystkie te komponenty może mieć trzy lub więcej nagłówków. Płyty produkcyjne mogą pomijać nagłówki lub, gdy miejsce jest ograniczone, mogą zapewniać dostęp do sygnału JTAG za pomocą punktów testowych.

głowic pinów 2,54 mm (0,100 cala) to:

  • ARM 2×10 pin (lub czasami starszy 2×7), używany przez prawie wszystkie systemy oparte na ARM
  • MIPS EJTAG (2 × 7 pinów) używany w systemach opartych na MIPS
  • 2 × 5-pinowy JTAG kompatybilny z Altera ByteBlaster, rozszerzony przez wielu dostawców
  • 2 × 5-pinowy AVR rozszerza Altera JTAG o SRST (aw niektórych przypadkach TRST i wyjście zdarzeń)
  • Texas Instruments 2 × 7 pin używane z procesorami DSP i produktami opartymi na architekturze ARM, takimi jak OMAP
  • 8-pinowy (jednorzędowy) ogólny PLD JTAG kompatybilny z wieloma kablami Lattice ispDOWNLOAD
  • MIPI 10-/20 (1,27 mm 050") do JTAG, cJTAG i SWD

Złącza te zwykle zawierają więcej niż tylko cztery standardowe sygnały (TMS, TCK, TDI, TDO). Zwykle dostarczane są sygnały resetowania, jeden lub oba spośród TRST (reset TAP) i SRST (reset systemu). Złącze zwykle dostarcza napięcie zasilania logiki testowanej płytki, dzięki czemu adaptery JTAG używają odpowiednich poziomów logicznych. Napięcie płyty może również służyć jako wejście debugera „obecna płyta”. Można zapewnić inne sygnały wejściowe lub wyjściowe zdarzeń lub linie we/wy ogólnego przeznaczenia (GPIO) w celu obsługi bardziej złożonych architektur debugowania.

Produkty z wyższej półki często wykorzystują gęste złącza (często 38-pinowe złącza MICTOR ) do obsługi szybkiego śledzenia w połączeniu z operacjami JTAG. Ostatnim trendem jest integrowanie płyt rozwojowych z interfejsem USB do JTAG, gdzie drugi kanał jest używany jako port szeregowy. zintegrowane łącza debugowania mogą znacznie zmniejszyć bałagan dla programistów) .

Sprzęt adaptera

Sprzęt adaptera jest bardzo zróżnicowany. Gdy nie jest zintegrowany z płytką rozwojową, wymaga krótkiego kabla do podłączenia do złącza JTAG na płycie docelowej; połączenie z hostem debugującym, takie jak łącze USB, PCI lub Ethernet; i wystarczającą ilość elektroniki, aby dostosować dwie domeny komunikacyjne (a czasem zapewnić izolację galwaniczną ). Może być potrzebny osobny zasilacz. Istnieją zarówno „głupie” adaptery, w których host decyduje i wykonuje wszystkie operacje JTAG; i „inteligentnych”, w których część tej pracy jest wykonywana wewnątrz adaptera, często sterowanego przez mikrokontroler. „Inteligentne” adaptery eliminują opóźnienia łącza dla sekwencji operacji, które mogą obejmować odpytywanie o zmiany statusu między krokami, i mogą odpowiednio oferować większą przepustowość.

Od 2018 roku najpopularniejszym podejściem są adaptery z łączem USB z hosta. Produkty z wyższej półki często obsługują Ethernet , z tą zaletą, że host debugowania może być dość zdalny. Adaptery, które obsługują szybkie porty śledzenia, zwykle zawierają kilka megabajtów bufora śledzenia i zapewniają szybkie łącza (USB lub Ethernet) umożliwiające przesyłanie tych danych do hosta.

portów równoległych są proste i niedrogie, ale są stosunkowo wolne, ponieważ wykorzystują procesor hosta do zmiany każdego bitu („ bit banging ”). Ich przydatność spadła, ponieważ większość komputerów w ostatnich latach nie ma portu równoległego. Problemem jest również obsługa sterowników, ponieważ użycie pinów przez adaptery było bardzo zróżnicowane. Ponieważ port równoległy jest oparty na poziomie logicznym 5 V, większość adapterów nie miała obsługi translacji napięcia dla docelowych napięć 3,3 V lub 1,8 V.

portu szeregowego RS-232 , których użyteczność podobnie spada. Na ogół obejmują one albo wolniejsze uderzanie bitów niż port równoległy, albo mikrokontroler tłumaczący jakiś protokół poleceń na operacje JTAG. Takie adaptery szeregowe również nie są szybkie, ale ich protokoły poleceń można generalnie ponownie wykorzystać na łączach o większej szybkości.

W przypadku wszystkich adapterów JTAG obsługa oprogramowania jest podstawowym problemem. Wielu dostawców nie publikuje protokołów używanych przez ich adaptery JTAG, ograniczając swoich klientów do łańcuchów narzędzi obsługiwanych przez tych dostawców. Jest to szczególny problem w przypadku „inteligentnych” adapterów, z których niektóre zawierają znaczną ilość wiedzy na temat interakcji z określonymi procesorami.

Rozwój oprogramowania

Większość środowisk programistycznych dla oprogramowania wbudowanego obejmuje obsługę JTAG. Zasadniczo istnieją trzy źródła takiego oprogramowania:

  • Dostawcy chipów mogą dostarczać narzędzia, zwykle wymagające adaptera JTAG, który dostarczają. Przykłady obejmują dostawców FPGA, takich jak Xilinx i Altera , Atmel dla linii produktów AVR8 i AVR32 oraz Texas Instruments dla większości swoich produktów DSP i mikro. Takie narzędzia są zwykle wysoce funkcjonalne i mogą być jedyną realną opcją dla wysoce wyspecjalizowanych układów scalonych, takich jak FPGA i DSP. Narzędzia programowe niższej klasy mogą być dostarczane bezpłatnie. Same adaptery JTAG nie są darmowe, chociaż czasami są dołączane do płyt rozwojowych.
  • Dostawcy narzędzi mogą je dostarczać, zwykle we współpracy z wieloma dostawcami chipów, aby zapewnić wieloplatformowe wsparcie programistyczne. Produkty oparte na ARM mają szczególnie bogaty rynek stron trzecich, a wielu z tych dostawców rozszerzyło swoją działalność na platformy inne niż ARM, takie jak MIPS i PowerPC . Dostawcy narzędzi czasami tworzą produkty oparte na wolnym oprogramowaniu, takim jak GCC i GDB , z obsługą GUI często przy użyciu Eclipse . Adaptery JTAG są czasami sprzedawane wraz z pakietami wsparcia.
  • Istnieją narzędzia open source . Jak wspomniano powyżej, GCC i GDB tworzą rdzeń dobrego łańcucha narzędzi i istnieją środowiska GUI, które je obsługują.

Całe takie oprogramowanie zwykle obejmuje podstawową obsługę debuggera: zatrzymywanie, zatrzymywanie, pojedyncze kroki, punkty przerwania, przeglądanie struktury danych i tak dalej. Narzędzia komercyjne zwykle zapewniają narzędzia, takie jak bardzo dokładne symulatory i analiza śladów, które nie są obecnie dostępne jako oprogramowanie typu open source.

Podobne standardy interfejsu

Serial Wire Debug (SWD) to alternatywny 2-stykowy interfejs elektryczny, który wykorzystuje ten sam protokół. Wykorzystuje istniejące połączenie GND. SWD wykorzystuje standardowy dwukierunkowy protokół przewodowy procesora ARM, zdefiniowany w interfejsie debugowania ARM v5. Dzięki temu debugger może stać się kolejnym AMBA w celu uzyskania dostępu do pamięci systemowej i rejestrów urządzeń peryferyjnych lub debugowania. Szybkość transmisji danych wynosi do 4 MB/s przy 50 MHz . SWD ma również wbudowane wykrywanie błędów. W urządzeniach JTAG z funkcją SWD, TMS i TCK są używane jako sygnały SWDIO i SWCLK, zapewniając programistom pracującym w dwóch trybach.

Zobacz też

Linki zewnętrzne

Pobrano z „ https://en.wikipedia.org/w/index.php?title=JTAG&oldid=1141187844 ”