Name: AD0032GV.PDF Version: 1.4 Autor: Gerhard Vieweg Erstellungsdatum: 01.03.2013 email: g.vieweg@goepel.com Thema: BScan / JTAG Testbus-Fehler wie geht man damit um? Diese Applikation Note erklärt Testbus-Fehlermeldungen, gibt Hinweise und Empfehlungen zum Design und zur Fehlersuche. Die Abschnitte FAQ sowie Typische Arbeitsfehler und Missverständnisse sollten eine weitere Hilfe bei der Fehlersuche sein. Einige Spezialfälle aus der Praxis werden ebenso diskutiert.
Inhalt Testbus: Grundlagen...3 Einleitung... 3 Voraussetzungen für den perfekten BScan / JTAG Testbus... 3 Testbus-Design: Notwendigkeiten und Fehler... 4 Testbusfehler...5 Erkennung von Testbusfehlern... 5 Besonderheiten... 5 Die Testbusfehlermeldung... 5 Ursachen für Testbusfehler... 5 Statische Testbusfehler... 6 Dynamische Testbusfehler... 7 Analysemöglichkeiten von Testbusfehlern... 7 Fehlermeldung...8 Testbusfehler wie ist er definiert?... 8 Typische Testbusfehler-Meldungen durch CASCON... 9 Weitere Analyse, Fehlersuch-Strategie... 11 Allgemeine Anleitung zur Fehlersuche... 11 CASLAN Programm TCK Check-up... 12 Prüfungen am TDO... 13 Weitere Prüfmöglichkeiten der Boundary Scan Probe... 15 Fehlersuche bei Testbusfehlern während der Testausführung... 20 Fehlersuche bei dynamischen Fehlern mittels Oszilloskop... 25 Spezialfälle aus der Praxis... 25 Fragenkatalog, Index, Hyperlinks... 29 Fragenkatalog... 29 FAQs... 30 Typische Arbeitsfehler und Missverständnisse... 32 Begriffe und Abkürzungen... 33 Sie benötigen weitere Hilfe?... 33 Anlagen... 34 Testprogramm TCK Check-up... 34 Literaturverweis... 34
Testbus: Grundlagen Einleitung Der Boundary Scan / JTAG Test benutzt ein serielles Übertragungsprotokoll. Seine fehlerfreie Übertragung erfordert einige Bedingungen, die sofern sie nicht eingehalten werden den Test wertlos oder unmöglich machen. Das vorliegende Dokument hilft, die Fehler zu erkennen und die Reaktionen des Systems richtig zu verstehen. Anleitung zur Fehlersuche in verschiedenen Situationen ist enthalten. Grundlagenwissen zum Standard IEEE 1149.1 und Kenntnis über das prinzipielle Arbeiten des Systems CASCON werden vorausgesetzt. Die hier verwendeten Screenshots beziehen sich auf die CASCON Version 4.6.2. Voraussetzungen für den perfekten BScan / JTAG Testbus 1. Alle BScan Ics setzen die Signale TMS und TCK so um, dass sie immer im gleichen TAP-State sind. Das bedeutet, dass TCK und TMS jeweils parallel an allen BScan Ics anliegen. 2. Die TCK Frequenz ist so gewählt, dass ein Abstand von mindestens 3 MHz zur maximalen TCK des langsamsten BScan Ics in der Kette ist. 3. Die Einstellungen zur Laufzeit-Kompensation (ADYCS ) sind so gewählt, dass das System sicher über den gesamten Bereich zwischen TCK min und TCK max synchronisiert. 4. Die Spannungspegel sind so definiert, dass sie dem jeweiligen BScan IC entsprechen. Ggf. werden dazu Pegelwandler eingesetzt. 5. Es gibt kein Übersprechen zwischen den Testbusleitungen. 6. Es gibt kein Übersprechen zwischen Testbusleitungen und anderen Signalen auf dem Board. Dynamische Bedingungen: 1. Die Signalgüte des TCK ist so, dass keine nennenswerten Überschwinger auftreten. Dazu muss ein gutes Kabeldesign und ein passender Leitungsabschluss gewählt werden. 2. Die Signalgüte des TCK ist so, dass die Schaltflanken frei von Einbrüchen sind. Dazu muss das Fan- Out der Treiber beachtet werden. 3. Die ADYCS Parameter sind optimal eingestellt. Das erlaubt dem System, zum richtigen Zeitpunkt die Daten von der UUT zu bewerten. Statische Bedingungen: 1. Die tatsächlichen Längen der Datenregister und des Instruktionsregisters entsprechen dem BSDL File. 2. Der Zusammenhang der Instruktionen und der damit ausgewählten Datenregister entspricht dem BSDL File. 3. Eventuelle Compliance Pattern sind im BSDL File definiert und werden auf dem Board eingehalten. 4. Anzahl und Reihenfolge der BScan Ics in der Scankette ist richtig im Scanpath Configuration File (CON) beschrieben. Das betrifft auch vorhandene Scan Router Ics. 5. Scan Router Ics werden mit der korrekten Adresse versorgt.
Testbus-Design: Notwendigkeiten und Fehler im Vorfeld beachten: 1. TAP Anschluss. Er kann über einen separaten Steckverbinder, über einen System-Steckverbinder geführt werden oder durch Adapternadeln realisiert werden. In jedem Fall müssen auch GND Anschlüsse bereitgestellt werden. 2. TAP Kabel benötigen an beiden Seiten GND Anschlüsse. Es handelt sich nicht um eine Abschirmung sondern um die Notwendigkeit, den Rückstrom der TAP-Signale zu übertragen. 3. GND Anschlüsse sollen in der Nähe der TAP-Anschlüsse liegen. Sie sollen separat zu Power Supply Anschlüssen vorhanden sein. 4. Leitungsabschlüsse sollen idealerweise am Leitungs-Ende sein. Bei mittleren und kleinen Boardgrößen kann der Abschluss am Steckverbinder liegen. Mögliche Varianten der Terminierung. Diese Variante hat Low-Potenzial bei nicht angeschlossenem Treiber. Diese Variante ist am meisten verbreitet. Hier ist der Abschlusswiderstand in zwei einzelne Widerstände aufgeteilt. Weil VCC über Abblockkondensatoren HF-mäßig Kurzschluss nach GND hat, sind beide Widerstände parallel geschaltet. Diese Variante hat High-Potenzial bei nicht angeschlossenem Treiber. Bei dieser Variante wird der Treiber besonders wenig belastet. Pegel nicht definiert, wenn der Treiber nicht angeschlossen ist. Evtl. Parallelschaltung mit hochohmigem Widerstand. (Niederohmiger) Serienwiderstand im Treiberausgang ist möglich, hat aber den Nachteil, dass möglichst nur ein Empfänger benutzt werden soll. Es gibt eine Spannungsverteilung längs der Leitung. Geringe Belastung des Treibers. Spannungsabfall über Rs Das sollte vermieden werden: 1. Zu viele BScan Ics parallel an TCK und TMS. Faustregel: Pro 5 Ics 1 Buffer. 2. Direkte Nachbarschaft von TCK zu anderen Signalen auch TAP Signalen auf Kabeln oder über lange Strecken auf dem Board. 3. Direkte Kopplung von /TRST und System-Reset. 4. Sternverdrahtung der TAP Signale TCK und TMS. 5. Komplizierte Jumper-Szenarios, um ein bestimmtes Scanketten-Design zu erzielen. Bei Missverständnissen kann viel Zeit verloren gehen.
Testbusfehler Erkennung von Testbusfehlern Sie werden nur bei CASLAN-Tests und bei der IEEE-1532-Programmierung erkannt. Bei jedem Scan-Befehl (DRSHIFT, IRSHIFT) wird ein Testbyte zusätzlich durch die Scankette geschoben. Wird dieses Testbyte fehlerhaft zurück gelesen, erscheint eine Testbusfehlermeldung und der Test wird abgebrochen. Falls die fehlerhafte Scanoperation ein DRSHIFT war, wird automatisch ein zusätzliches IRSHIFT zwecks Fehlerdiagnose ausgeführt. Weitere Details dazu im Abschnitt 0: Testbusfehler wie ist er definiert? Besonderheiten 1. Bei mehreren TAPs wird durch jede Scankette ein Testbyte geschoben. Somit kann für jede Scankette eine eigene Fehlermeldung erzeugt werden. 2. Bei der Verwendung von ScanRouter werden in den LOCALPATH-Anweisungen implizite DRSHIFTund IRSHIFT-Befehle verwendet. 3. Bei einer Multidrop-Konfiguration von ScanBridges oder Addressable Scan Ports wird für jeden ScanRouter ein eigenes Testbyte verwendet. 4. Bei der FLASH-Programmierung erfolgt keine Diagnose des Testbusfehlers, da wegen der Geschwindigkeitsoptimierung nicht genügend Informationen vorliegen. Die Testbusfehlermeldung Beispiel, weitere Beispiele im Abschnitt 0, Typische Testbusfehler-Meldungen durch CASCON. <0104> Testbusfehler bei DRShift; Diagnose durch IRShift: HIGH ab U1; U2-TDI und U1-TCK, -TMS, -TDO prüfen. <117> Es wurden 12 DRSHIFTs ausgeführt. Nr Informationsbestandteil Mögliche Werte 1 Art der fehlerhaften Scanoperation Testbusfehler bei DRSHIFT; Diagnose durch IRSHIFT: Testbusfehler bei DRSHIFT; Diagnose durch IRSHIFT ohne Testbusfehler: 2 Fehlerhaft gemessenen Pegel HIGH ab U1 LOW ab FAIL ab 3 Fehlerlokalisierung innerhalb der Scankette 4 Fehlerlokalisierung innerhalb des CASLAN-Programmes Weitere Details zur Fehlermeldung im Abschnitt Fehlermeldung. U2-TDI und U1-TCK, -TMS, -TDO prüfen. <dev1>- TDI und <dev2>-tck, -TMS, -TDO prüfen. <dev1> und <dev2> sind benachbarte Scanbausteine. Einer von beiden kann auch der Controller sein. Es wurden 12 DRSHIFTs ausgeführt. Ursachen für Testbusfehler Die möglichen Testbusfehler lassen sich in eine der folgenden Kategorien einordnen. Eine feinere Unterscheidung finden Sie in den folgenden Abschnitten. Nr Ursache Typisches Fehlerbild 1 Fertigungsfehler Tritt nur bei manchen Boards auf. 2 Falsche Parametrisierung (TCK Frequenz, Delays, Spannungen) Kann durch niedrige Frequenz (1 MHz oder kleiner) und Kontroller der Spannungen ausgeschlossen werden. 3 Schlechte Testbus-Signalqualität Typischerweise wechselnde Fehlerorte und Meldungen;
4 Fehlerhafte Verdrahtung Controller UUT; insbesondere TDI / TDO vertauscht 5 Asynchrones Reset des Testbusses (TRST, Power, Compliance-Pins, Watchdog) 6 Falsche Modellierung / Beschreibung (Scanpath Configuration File, BSDL-Files) 7 Fremd -Pins im Testbus (Buffer im Testbus nicht transparent, andere Pins unerlaubt aktiv) Board-Design-Fehler Application Note Bei niedrigen TCK-Frequenzen bessere aber nicht fehlerfreie Funktion Jeder Test ist beim ersten SHIFT fehlerhaft. LOW ab <TDO Device der UUT> und Controller TDI prüfen. Low/High hängt vom Pull-Down/-Up-Widerstand ab. Reset kann statisch anliegen, dann wie bei fehlerhafter Verdrahtung. Bei dynamischen Resets kommt der Testbusfehler typischerweise immer an der gleichen Stelle im CASLAN (Ausnahme: Watchdogs) und an der selben Stelle in der Scankette. Testbusfehler konstant an gleicher Stelle im CASLAN, wenn falsche Registerlängen auftreten. IRSHIFT meistens fehlerfrei; Asynchrones Reset durch falsche Zell-Port-Zuordnung möglich Wie beim asynchronen Reset 8 Non-compliant Verhalten von Bausteinen Fehler beim Benutzen bestimmter Register Statische Testbusfehler Es gibt keinen Zusammenhang zwischen der TCK-Frequenz und dem Fehlerbild. Der Fehler ist konstant. Typische Fälle: Fehlerbild Mögliche Ursache Diagnose 1 TDO (Test Data Out) der UUT liefert unterschiedliche Pattern, jedoch verschieden von konstant 0 oder 1. Falsches BSDL File. Registerlängen (Instruktionsregister oder Datenregister) weichen ab. Diagnose im Debugger, TCK Step Mode ist möglich, wenn die Abweichung gering ist. Man kann das verschobene Testbyte erkennen, wenn die tatsächliche Kettenlänge kürzer ist. Wenn sie länger ist, werden einige oder alle Bits des Testbytes verschluckt, sodass die Diagnose unsicher ist. Ein Dummy-BSDL mit sehr langem Boundary Scan Register kann helfen, den Ort des Testbytes ausfindig zu machen. 2 TDO (Test Data Out) der UUT liefert konstant 0 oder 1. 3 IRSHIFT ist fehlerfrei, DRSHIFT bringt Fehler bei der Instruktion SAMPLE oder - Designfehler TAP-Kabel - Designfehler TAP auf dem Board - Compliance Pattern nicht erfüllt - System-Reset oder /TRST aktiv - TDO Kurzschluss nach GND oder Treiber mit festem Pegel Falsches BSDL File. Länge des BScan Register weicht ab. Diagnose mit BScan-Probe, siehe Abschnitt Weitere Prüfmöglichkeiten der Boundary Scan Probe Prüfen, ob TDO des BScan IC nur in SHIFT-IR / SHIFT-DR aktiv wird. Siehe 1, bezogen auf das mit der Instruktion selektierte Datenregister.
EXTEST Dynamische Testbusfehler Die TAP (Test Access Port) Operation basiert auf einer flankengesteuerten Arbeitsweise. Das TCK Signal dient dem Synchronisieren. Es ist daher das kritische Signal unter den TAP Signalen. So können Überschwinger durch Fehlanpassung der Signalleitung als extra Clock interpretiert werden. Beim Design des Verbindungskabels zwischen Controller und UUT sowie auf der UUT selber, sind die Grundregeln für ein HF-gerechtes Design anzuwenden. Unter dynamischen Testbusfehlern versteht man solche Fehler, die einen Zusammenhang mit der TCK-Frequenz haben. Das Ändern der TCK-Frequenz kann PASS oder FAIL zum Ergebnis haben. TCK Signal Diese Abbildung zeigt die Gefahrenquelle für eine unsichere Synchronisation auf dem Testbus. Wegen des Nichtbeachtens des Fan-Outs entstehen Einbrüche, die durch manche BScan ICs als extra Clock gesehen werden. Solche Spikes sind manchmal sehr schmal und nur mit entsprechend genauer Messtechnik darstellbar. Über-/Unterschwinger die häufigste Ursache für instabilen Testbus. Hier fehlt offensichtlich die Terminierung. Es gibt keine Chance zur Synchronisierung. Auch das Ändern der TCK Frequenz bringt keine Abhilfe. Analysemöglichkeiten von Testbusfehlern Zur effektiven Suche der Testbusfehler-Ursache können vor dem Einsatz weiterer Messtechnik einige Fragen beantwortet werden, um gezielt Messungen vornehmen zu können. Hierzu sind oft mehrere Tests mehrfach durchzuführen. Nr Frage 1 Kommt der Testbusfehler beim ersten DRSHIFT / IRSHIFT? 2 Enthält die Fehlermeldung HIGH oder LOW und Controller TDI? 3 Kommt der Testbusfehler bei jeder Wiederholung? 4 Kommt der Testbusfehler bei jedem Test? 5 Kommt der Testbusfehler bei tiefen Frequenzen (TCK < 1 MHz)
6 Tritt der Fehler auf allen Boards auf? Werden alle diese Fragen mit ja beantwortet, liegt meist ein prinzipielles Problem vor, da auf den Testbus überhaupt nicht zu gegriffen werden kann. Hier kommen vor allem die Fehlerursachen fehlerhafte Verdrahtung, statisches asynchrones Reset (insbesondere kein Power) und Fremdpins im Testbus in Frage. Alternativ kann der letzte Baustein in der Kette (der TDO der UUT treibt) die Fehlerursache sein. Prüfen: Compliance-Pins, TRST oder Testbuspins. Wird eine der Fragen mit nein beantwortet, so funktioniert der Testbus wenigstens partiell und man kann aufbauend auf dem funktionellen Teil weitere Untersuchungen anstellen. Fehlermeldung Testbusfehler wie ist er definiert? Ein Testbusfehler liegt dann vor, wenn das Testbyte nicht korrekt erkannt wird. Zur Fehlererkennung genügt ein Bit Abweichung. Der Exitcode ist immer 65534. Das Testbyte ist eine durch CASCON eingebaute Möglichkeit, die Durchlässigkeit des Testbusses zu prüfen. Es wird zusätzlich zur aktuellen Kettenlänge des Prüflings während SHIFT-DR und SHIFT-IR zum Prüfling in der Scankette transportiert. Weil das Testbyte zusätzlich transportiert wird, außerdem als erstes den Controller verlässt, muss es folglich am Abschluss der Schiebe-Operation (Shift) am seriellen Ausgang der UUT wieder erscheinen. Das Testbyte ist 100%-ige Garantie für die Synchronisation der BScan Ics auf dem Board und dem Controller. Jedoch ist dies keine 100%-ige Garantie für fehlerfreie Testbus-Arbeit, denn auch einzelne Bits außerhalb des Testbytes können verfälscht werden. Das trifft aber eher selten zu. Der Nachweis des Testbytes ist also eine gute Test-Möglichkeit für die Kettenlänge. Die berechnete Kettenlänge ergibt sich aus den BScan Ics in der Scankette in der aktuellen Situation. Die CASLAN Kommandos zum Aktivieren des Testbusses sind IRSHIFT und DRSHIFT. Sie führen zu einem Durchlauf der Graphenbereiche IR-Scan und DR-Scan. Beachten Sie: Bei IRSHIFT ist die Kettenlänge konstant, bei DRSHIFT hängt die Länge vom ausgewählten Datenregister ab. Eine Instruktion wählt das Datenregister aus, welches sich für nachfolgende DRSHIFTs zwischen TDI und TDO befindet. Ein Datenregister wird durch eine Instruktion ausgewählt bzw. wird durch den Standard als default definiert. Default ist hier das ID-Code Register (wenn vorhanden), in allen anderen Fällen das Bypassregister. Achtung: Das Testbyte darf bei der Testausführung nicht abgeschaltet werden. Andernfalls wird die Sicherheit für die UUT beim Testen bezüglich Testbusfehler außer Kraft gesetzt. In Ausnahmen, die technisch begründet sind, kann (muss) das Testbyte vorübergehend ausgeschaltet werden. Ein Testbusfehler kann stabil sein. Er kann sich aber auch dynamisch verhalten. Weiter unten sehen wir mögliche Fehlerfälle mit typischen Ursachen dazu.
Typische Testbusfehler-Meldungen durch CASCON Beispiel 1 Einfacher Testaufbau *.CON (SCANPATH 1 (DEV U2 EPM7032AETC44 ) (DEV U1 XC9572XL_TQ100 ) ) Meldung Bedeutung, mögliche Fehler Testing boundary register U2... <0108> Testbusfehler bei DRShift; IRShift ohne Testbusfehler: FAIL ab BScan-Controller; U1-TDI und BScan-Controller-TCK, -TMS, -TDO prüfen. <117> Es wurden 4 DRSHIFTs ausgeführt. Länge IR OK, Datenregister (hier das BScan Register) falsche Länge BSDL und Compliance Pattern prüfen Meldung Bedeutung, mögliche Fehler <0104> Testbusfehler bei DRShift; Diagnose durch IRShift: HIGH ab U1; U2-TDI und U1-TCK, -TMS, -TDO prüfen. <117> Es wurden 1 DRSHIFTs ausgeführt. Verbindung U1:TDO => U2:TDI gestört U1 hat kein TMS oder TCK U1 ist im Reset Mode U1 Compliance Pattern nicht erfüllt Meldung Bedeutung, mögliche Fehler <0101> Testbusfehler bei DRShift; Diagnose durch IRShift: LOW ab BScan-Controller; U1-TDI und BScan-Controller-TCK, - TMS, -TDO prüfen. <117> Es wurden 1 DRSHIFTs ausgeführt. Verbindung Controller:TDO => U1:TDI gestört Meldung Bedeutung, mögliche Fehler <0101> Testbusfehler bei DRShift; Diagnose durch IRShift: LOW ab U2; BScan-Controller-TDI und U2-TCK, -TMS, -TDO prüfen. <117> Es wurden 1 DRSHIFTs ausgeführt. UUT keine Versorgungsspannung SFX-TAP Module der UUT nicht zugewiesen SFX-TAP Module falsche TAP-Spannungs-Einstellungen Testbuskabel fehlerhaft Verbindung U2:TDO => Controller:TDI gestört U2 hat kein TMS oder TCK U2 im Reset Mode U2 Compliance Pattern nicht erfüllt
Beispiel 2 Scanpfad-Aufteilung mit Scanrouter IC *.CON (SCANPATH 1 (SCANROUTER U100 scansta112_b0 (ADDRESS 03h) (LOCALPATH 7 (DEV U204 XC9536XL-10VQ44C ) ) (LOCALPATH 6 ) (LOCALPATH 5 (DEV U203 XCR3064XL-VQ44C ) ) (LOCALPATH 4 (DEV U202 XC9572XL-10VQ44C ) ) (LOCALPATH 3 ) (LOCALPATH 2 (DEV U201 XCR3064XL-VQ44C ) ) (LOCALPATH 1 (DEV U200 XC9536XL-10VQ44C ) ) ) ) Meldung <0103> Testbusfehler bei IRShift: LOW ab U100; BScan-Controller-TDI und U100-TCK, -TMS, -TDO prüfen. <117> Es wurden 0 DRSHIFTs ausgeführt. Bedeutung, mögliche Fehler Scan Bridge (Adresse 3H) nicht gefunden Die Meldung beinhaltet zwei Informationen: Testbusfehler für den Scan Router-eigenen Scanpfad (primärer TAP) und Adressierungsfehler. UUT keine Versorgungsspannung Testbuskabel fehlerhaft Adresse falsch Meldung Bedeutung, mögliche Fehler <0106> Testbusfehler bei IRShift: HIGH ab U202; U203-TDI und U202-TCK, -TMS, -TDO prüfen. <117> Es wurden 2 DRSHIFTs ausgeführt. U202 hat kein TMS oder TCK U202 im Reset Mode U202 Compliance Pattern nicht erfüllt Verbindung U202:TDO => U203:TDI gestört
Weitere Analyse, Fehlersuch-Strategie Es werden Antworten auf diese Fragen benötigt: Application Note Nr Frage weiter 1 Ist der Fehler sporadisch? Ja: Weiter mit 3 Nutzen Sie Run Continuous Run 2 Verändert sich der Inhalt der Fehlermeldung? Ja: Prüfen Sie die Stabilität des Testbus, siehe Abschnitt CASLAN Programm TCK Check Up 3 Ist der Fehler von der TCK-Frequenz abhängig? ADYCS prüfen, Kabeldesign prüfen 4 Tritt der Fehler nur bei bestimmten Tests auf? Ja: weiter mit 5 Nein: Prüfen Sie die Stabilität des Testbus, siehe Abschnitt CASLAN Programm TCK Check Up 5 Tritt der Fehler am Anfang des Tests auf? Ja: weiter im Abschnitt Statische Testbusfehler 6 Tritt der Fehler in der Mitte des Tests auf? Ja: weiter mit 7 7 Ist der fehlerhafte Prüfschritt konstant auch bei verschiedenen TCK? Ja: weiter im Abschnitt Fehlersuche bei Testbusfehlern während der Testausführung Nein: auf asynchrones Reset prüfen 8 Tritt der Fehler auf einem neuen Board auf? Ja: Evtl. Programm fehlerhaft; Debug erforderlich 9 Tritt der Fehler nur auf bestimmten Boards auf? Ja: Evtl. Fertigungsfehler 10 Ist der Fehler-Ort am Anfang der Kette = TDI UUT? Ja: Kabel zum Controller, evtl. Pegel 11 Ist der Fehler-Ort am Ende der Kette = TDO UUT? Ja: weiter im Abschnitt Statische Testbusfehler 12 Ist der Fehler-Ort in der Mitte der Kette? Jumper, Widerstände (TDI-TDO), 13 Tritt der Fehler bei einer bestimmten Kabel- Konfiguration auf? Ja: Kabel Design prüfen Allgemeine Anleitung zur Fehlersuche Eine einfache Methode ist die Ausführung einer IRSHIFT Anweisung in einem manuell geschriebenen Testprogramm. Das erfordert kein Laden eines bestimmten Instruktionscodes. In dem Fall wird automatisch die Instruktion BYPASS geladen. Weil hier auch kein IC-Name angegeben wird, werden alle vorhandenen BScan ICs automatisch mit BYPASS geladen. Ablauf: Executables / Manually / New / <test_name> Files / CASLAN / Zum Prüfen der TCK-Frequenz-Abhängigkeit kann in den Execute Optionen des Tests die TCK verändert werden. Use Special TCK Frequency. Das Ziel ist festzustellen, ob es TCK-Bereiche gibt, die fehlerhaft bzw. fehlerfrei sind. CASLAN BEGIN IRSHIFT; END. Effektiver geht das, wenn im Testprogramm selber die TCK verändert wird. Das wird im CASLAN Test TCK Chek-Up gemacht, außerdem werden die Frequenz und PASS / FAIL Information angezeigt.
Im Debugger kann man in jedem Testprogramm (Ausnahmen: In-System-Programmierung FLASH, SVF, JAM/STAPL) direkt im Command Window das IRSHIFT benutzen. Es genügt dazu, das Programm im Debugger zu starten, das Command Window zu öffnen und IRSHIFT; einzutragen. Debugger Start, das Programm wartet vor der ersten Instruktion. Command Window öffnen, IRSHIFT; eintragen CASLAN Programm TCK Check Up Das Programm kann in jedes Projekt eingebunden werden, weil keine Bscan Ics adressiert werden. Im Wesentlichen gibt es die beiden Instruktionen IRSHIFT und TCK. Das Testbyte ist ausnahmsweise ausgeschaltet, damit erkannt werden kann, ob der PASS Bereich Unterbrechungen hat oder nicht. CASLAN Code siehe Anhang. Der Inhalt des Ergebnisfensters besteht aus der TCK-Frequenz-Skala und darunter ein. Für PASS oder F für FAIL. FAIL trifft immer dann zu, wenn der Capture Wert des (der) Instruktionsregister(s) vom Erwartungswert abweichen. Optimale Einstellung, keine nennenswerte Unterbrechungen des PASS Verlaufes ( ) Fehlerhafter Leitungsabschluss oder mangelhafte ADYCS Einstellung. Es gibt Gut und Schlecht - Abschnitte, die sich abwechseln. Es ist keine Lösung ist, sich eine Gut TCK beim Testen auszusuchen sondern es muss die Ursache für das Verhalten abgestellt werden.
Die ADYCS Einstellungen können von Hand vorgenommen werden; ab CASCON 4.4.1 kann man die ADYCS Parameter unter Measure TCK-TDO Delay bei den SFX-TAP-Transceivern ermitteln lassen: Zweite Einstellkarte dazu. Prüfungen am TDO Debugger, TCK Step Mode: Den Step Mode im Debugger erreicht man über diese beiden Wege: Options / Step Mode oder Anklicken in der rechten unteren Ecke im Debug- Fenster. Die höchste Priorität hat TCK, die Felder IR und DR werden dann nicht berücksichtigt.
Die Signal-Namen der Spalten-Überschriften entsprechen den Signalen des Controllers. Farbliche Unterscheidung zwischen Testbyte und den einzelnen BScan ICs machen die Bitmuster anschaulicher. Das Testbyte wird als erstes aus dem Controller getaktet. Es hat den Vektor 52h. Das LSB wird zuerst geschoben. Die Signalnamen im TCK- Step-Window entsprechen den Controller-Signalen. Demnach ist TDO das TDO des Controllers usw. Da 8 Bit zusätzlich zur realen Kettenlänge auf dem Board transportiert werden, muss das Testbyte am Schluss des Transportes in den Controller einlaufen. Der unveränderte Wert dieses Vektors 52H beweist die richtige Funktion der Scankette und die Übereinstimmung zwischen Bibliotheksmodellen (BSDL) und Realität bezüglich IRSHIFT.
Mit der Boundary Scan Probe z.b. kann man prüfen, ob ein TDO eines BScan ICs sich richtig verhält: Im Debugger / TCK-Step Mode wird ein IRSHIFT ausgeführt. Prüfen, ob das TDO nur aktiv im TAP State ShiftIR / ShiftDR ist die beiden ersten Bits bei ShiftIR 01b sind (LSB=1) Letzteres funktioniert deshalb, weil die beiden LSB Bit Capture-Werte des Instruktionsregisters konstant im Standard mit 01b definiert sind. Dieses Verhalten ist an allen BScan ICs identisch. Alle BScan ICs bringen gleichzeitig am TDO 01b, was man im Debugger überprüfen kann. Lediglich die weiteren Bits sind vom Chip abhängig, siehe BSDL File / Library / Instruction Capture Values. Diese Prüfung bestätigt die richtige Funktion am untersuchten IC von: TCK TMS TDO Chip Versorgungsspannung Reset des TAP Controllers (ist hier nicht aktiv) Bei Abweichungen sind die o.g. Signale bzw. Spannungen zu prüfen. Besonders bei konstant 0 oder 1 ist auf mögliche Kurzschlüsse zu Powernetzen oder aktiven Treibern zu prüfen. Weitere Prüfmöglichkeiten der Boundary Scan Probe Neben dem oben Genannten kann die Boundary Scan Probe auch verwendet werden, um: die Längen von IR und Datenregistern zu prüfen den IDCode zu prüfen den Zusammenhang zwischen IR Code und Datenregisterlänge zu prüfen die Zuordnung BScan Registerzellen und Pins zu prüfen Signale TMS, TCK, TDO auf einem Board zu verfolgen Weitere Informationen dazu im Abschnitt Note: Starting from CASCON 4.6.0, you need CON depending versions of the test program. The version below reflects version for TAP1 only. -- ------------------------------------------------------------------- -- -- Caslan File -- -- Name : TCK Check Up.CAS -- Date : 15.04.2005 -- Author : vieweg -- -- ------------------------------------------------------------------- -- Version Date Change -- 1.0 15.04.2005 Creation -- 1.1 13.12.2006 Update compressed output format -- 1.2 21.12.2006 Update TAP selection -- 1.4 01.03.2013 Update TAP selection according to CON file -- -- ------------------------------------------------------------------- PROGRAM 'TCK Check UP'; VAR v_tck : INT; v_2 : INT; v_3 : 16; vsel : 16;
failflag : 1; vloopcnt : INT; LABEL NewSelect; PROC ptap3; -- procedure keyword 'PROC' and name 'ProcName' BEGIN -- place procedure code between 'begin' and 'end;' WRITE (' '); FOR v_tck := 1 TO 79 DO --20 MHz -- FOR v_tck := 1 TO 39 DO --10 MHz TCK v_tck; IRSHIFT; IF failflag ==1 THEN WRITE ('F'); LD failflag, 0; ELSE WRITE ('.'); TAPRESET; PROC p_tap_test; BEGIN; WRITELN (' 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20'); WRITELN ('........................................................... '); WRITE (' '); FOR v_2 := 1 TO 79 DO --20 MHz TCK v_2; IRSHIFT; IF failflag ==1 THEN WRITE ('F'); LD failflag, 0; ELSE WRITE ('.'); WRITELN (' 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40'); WRITELN ('............................................................ '); WRITE (' '); FOR v_2 := 80 TO 159 DO --40 MHz TCK v_2; IRSHIFT; IF failflag ==1 THEN WRITE ('F'); LD failflag, 0; ELSE WRITE ('.'); WRITELN (' 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60'); WRITELN ('............................................................ '); WRITE (' '); FOR v_2 := 160 TO 239 DO --60 MHz TCK v_2; IRSHIFT; IF failflag ==1 THEN WRITE ('F'); LD failflag, 0; ELSE WRITE ('.');
WRITELN (' 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80'); WRITELN ('............................................................ '); WRITE (' '); FOR v_2 := 240 TO 319 DO --80 MHz TCK v_2; IRSHIFT; IF failflag ==1 THEN WRITE ('F'); LD failflag, 0; ELSE WRITE ('.'); PROC ploop20mhz; BEGIN; WRITELN (' 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20'); WRITELN ('........................................................... '); LOOP vloopcnt DO CALL ptap3; WRITELN ('........................................................... '); WRITELN (' 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20'); PROC pactionselect; BEGIN; READSELECTION ('Action select', vsel, '1 x 80 MHz', '100 x 20 MHz', '1000 x 20 MHz', 'Exit'); SWITCH vsel CASE 0: CASE 1: vloopcnt := 100; CALL ploop20mhz; CASE 2: vloopcnt := 1000; CALL ploop20mhz; CASE 3: STOP 200; CALL p_tap_test; PROC p_fail; BEGIN; -- WRITE (' FAIL'); LD failflag, 1; /************************************ MAIN ***********************************/ BEGIN ON_ERROR p_fail; NewSelect: LD vsel, 0; WRITELN ('TAP select'); READSELECTION ('TAP selec', vsel, 'TAP1', 'TAP2', 'TAP3', 'TAP4', 'TAP5', 'TAP6', 'TAP7', 'TAP8', 'Exit'); SWITCH vsel CASE 0: SCANPATH (1 SHIFT);--, 2 PARK, 3 PARK, 4 PARK, 5 PARK, 6 PARK, 7 PARK, 8 PARK);
WRITELN (' ================================= TESTING TAP1 ================================'); CALL pactionselect; CASE 1: WRITELN (' chosen TAP does not exist'); JMP NewSelect; Application Note --SCANPATH (1 PARK, 2 SHIFT, 3 PARK, 4 PARK, 5 PARK, 6 PARK, 7 PARK, 8 PARK); --WRITELN (' ================================= TESTING TAP2 ================================='); CALL pactionselect; CASE 2: WRITELN (' chosen TAP does not exist'); JMP NewSelect; --SCANPATH (1 PARK, 2 PARK, 3 SHIFT, 4 PARK, 5 PARK, 6 PARK, 7 PARK, 8 PARK); --WRITELN (' ================================= TESTING TAP3 ================================='); CALL pactionselect; CASE 3: WRITELN (' chosen TAP does not exist'); JMP NewSelect; --SCANPATH (1 PARK, 2 PARK, 3 PARK, 4 SHIFT, 5 PARK, 6 PARK, 7 PARK, 8 PARK); --WRITELN (' ================================= TESTING TAP4 ================================='); CALL pactionselect; CASE 4: WRITELN (' chosen TAP does not exist'); JMP NewSelect; --SCANPATH (1 PARK, 2 PARK, 3 PARK, 4 PARK, 5 SHIFT, 6 PARK, 7 PARK, 8 PARK); --WRITELN (' ================================= TESTING TAP5 ================================='); CALL pactionselect; CASE 5: WRITELN (' chosen TAP does not exist'); JMP NewSelect; --SCANPATH (1 PARK, 2 PARK, 3 PARK, 4 PARK, 5 PARK, 6 SHIFT, 7 PARK, 8 PARK); --WRITELN (' ================================= TESTING TAP6 ================================='); CALL pactionselect; CASE 6: WRITELN (' chosen TAP does not exist'); JMP NewSelect; --SCANPATH (1 PARK, 2 PARK, 3 PARK, 4 PARK, 5 PARK, 6 PARK, 7 SHIFT, 8 PARK); --WRITELN (' ================================= TESTING TAP7 ================================='); CALL pactionselect; CASE 7: WRITELN (' chosen TAP does not exist'); JMP NewSelect; --SCANPATH (1 PARK, 2 PARK, 3 PARK, 4 PARK, 5 PARK, 6 PARK, 7 PARK, 8 SHIFT); --WRITELN (' ================================= TESTING TAP8 ================================='); CALL pactionselect; CASE 8: STOP 100; END. JMP NewSelect;
Literaturverweis Application Note
Fehlersuche bei Testbusfehlern während der Testausführung Der Testbus funktioniert anfangs, wird aber vor der normalen Beendigung des Tests gestört. Eine Diagnose kann wegen dem Abbruch nicht generiert werden, es wird lediglich die Testbus-Fehler-Meldung erzeugt. Die folgende Methode kann benutzt werden, wenn der Fehler konstant im gleichen Prüfschritt auftritt. Achtung: Bei zeitlich abhängigen Fehlern kann der fehlerhafte Prüfschritt sich verschieben. Ziel Erkennen, welcher BScan Treiber die Störung verursacht. Strategie Im Debugger erkennen: welcher Testschritt, welcher BScan Treiber, welcher Pegel Methode Zusätzliche DRSHIFT im CAS einbauen (automatisch im Debugger ab CASCON 4.4.1) CAS Zeile finden: Debugger STEP Mode BScan Treiber finden: Debugger Command Window, CAS Zeile aufbrechen Ablauf Schritt 1: Fehlerreport <0101> Testbusfehler bei DRShift; Diagnose durch IRShift: LOW ab U2; Bscan-Controller-TDI und U2-TCK, -TMS, -TDO prüfen. <118> Es wurden 4 DRSHIFTs, davon 1 DRSHIFTs/ATG ausgeführt. Schritt 2: Debugger Es gibt keine Breakpoints, die Optionen für Pin Toggler sind de-aktiviert. Der Test wird normal gestartet. Test bricht bei Drive 3 ab. Der gelbe Pfeil zeigt, welcher DrShift zum Fehler geführt hat. Pfeil nach links = Schritt wurde ausgeführt
Schritt 3: Debugger Options / Insert DrShifts Test bricht nach Zeile 65 ab Schritt 4: Debugger Zeile 65 in Command Window kopieren und Device Name einfügen 2x DRSHIFT einfügen
Schritt 5: Debugger Source Window Breakpoint auf Zeile 65 Schritt 6: Debugger Debugger: Reset Debugger: Run Command Window Cursor auf erste Zeile Run Prüfen, ob FAIL
Schritt 7: Zeile halbieren ); -- Debugger: Reset Debugger: Run Command Window Cursor auf erste Zeile Run Prüfen, ob FAIL Schritt 8: Debugger Command Window Schritte wiederholen, prüfen, ab welchem DH/DL kein FAIL mehr vorhanden ist Hier ist U1:PB02_15/C der Verursacher Schritt 9: Schaltung prüfen, warum U1:PB02_15/C den Testbus stören kann. Fehlersuche bei Testbusfehlern während der Testausführung, ab CASCON 4.6.0 Beginnend mit CASCON 4.6.0 wird die Fehler-Eingrenzung vereinfacht. Dazu gibt es diese Generator- Einstellung beim Interconnection-, RAM-Interconnection- und Cluster- Test.
Im Ergebnis wird im beim Generieren des CASLAN Files eine separate Zeile pro Treiber-Aktivität angelegt. Damit entfällt das Splitten der Zeilen wie im vorigen Abschnitt dargstellt und die Fehler-verursachende Aktion wird schneller gefunden.
Fehlersuche bei dynamischen Fehlern mittels Oszilloskop Hiermit kann geprüft werden, ob das TDO sich mit fallender TCK Flanke ändert. Definition: Steigende TCK Flanke nimmt Eingänge auf (Capture), fallende ändert Ausgänge (Update). Gleiches trifft für Shift zu. Es gilt: rot = TCK; blau = TDO Richtige Arbeitsweise; TDO ändert sich immer mit fallender Flanke. Fehlerhafte Arbeitsweise; manchmal ist das Update mit fallender Flanke, manchmal mit steigender und fallender. Die Ursache kann eine Reflexion oder Spikes auf TCK sein. Auch Signal-Anstiegszeiten können kritisch sein. Dazu das Datenblatt prüfen. Spezialfälle aus der Praxis Diese Fälle sind nicht repräsentativ, zeigen aber, dass schwierige Fälle auftreten können. Häufig war das Verhalten nicht Standard-konform. Chip, Hersteller, Fehlerbild 1 <Typ Name durch NDA geschützt> Statt 1 sind 3 BScan Kerne in einem Package Nur einer davon im JTAG Mode verwendbar 2 <Typ Name durch NDA geschützt> Im Mode SAMPLE / PRELOAD ist die Länge des BScan Registers kürzer als im EXTEST; die Funktion ist jedoch korrekt 3 Infineon MPC8548E-1333_CFCBGA_PGEQ1 Beim TAP-Übergang vom Update-DR => Run- Test/Idle => Select-DR-Scan => wird kein UPDATE durchgeführt, wenn der Mode EXTEST geladen ist. 4 Texas Instruments TMS320C6713 Sporadisch Testbusfehler, nach Reset oft PASS. Sporadisch FAIL, dabei stimmt die Länge des BScan Registers nicht. Ursache, Work-Around Fehlerhaftes BSDL File; 3 getrennte Library Modelle anlegen IR und BScan Register-Längen ermitteln 2 Dummy Modelle anlegen, diese Ics werden später im Bypass Mode gehalten: Globale Extended Generator Settings (*.EGS), (DEVICES (DEV (INSTRUCTION BYPASS)) Designfehler im Chip; Im SAMPLE Mode Testbyte ausschalten, danach wieder aktivieren Globale Extended Generator Settings (*.EGS, (CASLAN (PRESHIFT_0 SET TEST_BYTE, OFF;) (PREEXTEST SET TEST_BYTE, 052H;)) Designfehler im Chip; Generate Options / Time between Update and Capture = Fast (2.5 TCK) Anwendungsfehler; Compliance Pattern wurden nicht eingehalten: TMS320C6713:Reset_Z Pin hatte kein LOW, weil dadurch Flash-Zugriff auf dem Board verhindert würde.
Der IC Hersteller garantiert nur die Funktion, wenn die Compliance Pattern eingehalten werden. 5 <Typ Name durch NDA geschützt> Im TAP State PAUSE-DR hängt sich die TAP Operation auf; Weiterarbeit nur mit Test Logic Reset Board Design ändern: Trennung zwischen TMS320C6713:Reset_Z und Flash:Reset Um den TAP-Zustand PAUS-DR zu vermeiden, gibt es zwei Einschränkungen: die UUT darf nur 1 TAP haben Testprogramm Generator (Intercon, RAM- Intercon), Time between Update and Capture = Normal 6 Schwer zu erklärende Testbusfehler; bei Untersuchungen mit dem Oszilloskop lassen sich am TDO teilweise richtige und teilweise Mittenpegel nachweisen. 7 Xilinx Spartan 3E bringt Testbusfehler, wenn die Instruktion SAMPLE geladen wird. Nachteil: Pull-Widerstands-Tests haben höheren Fehlerschlupf Fehler im Board Design. Es waren Widerstände für verschiedene Bestückungsvarianten vorgesehen, die jedoch falsch bestückt waren. Dadurch waren 2 TDO parallel geschaltet. Fehler im Board Design. Das /TRST Pin war mit einem IO des Spartan 3E verbunden, außerdem gab es einen Pull-Up von 4k7. Keine Verbindung zum /TRST des Controllers. Xilinx Support: It is expected to see I/Os pulled up/down with unconfigured device when SAMPLE instruction is loaded and the TAP controller switch to Update- IR state. If HSWAP is high, you will see all I/O pulled down but if HSWAP is low you will see all I/Os pulled up. The workaround we give to customer is then to use BSDLAnno and set the I/O as needed if the pull-up/down effect is problematic.
8 Ein BScan IC bringt Testbusfehler, andere Ics in der gleichen Kette sind fehlerfrei. Das fehlerhafte IC (IC1) hat in der TCK Leitung einen Serienwiderstand, außerdem führt von dort eine Leitung des TCK in den Adapter, die mit dem Ende offen ist (= Stichleitung). Die Periodendauer der Welligkeit nach der Schaltflanke ist von der Länge der Leitung abhängig. Erklärung: Die offene Leitung erzeugt eine Reflektion. Die Leitung ist kapazitiv belastet. Blau: TCK am fehlerhaften IC. Deutliche Spikes auf den Flanken, somit ist eine Synchronisation ausgeschlossen. Die Spikes liegen in einem kritischen Spannungsbereich und erscheinen für IC1 als extra Flanken. Rot: Auch hier sind die Spikes zu sehen. Wegen dem Serienwiderstand liegen diese in einem Pegelbereich, der nicht stört. Sie sind aber bei der Fehlersuche ein Indiz. Lösung: Trennen der Verbindung zum Adapter. 9 BScan Kombination mit MDA Tester. Der Testbus ist instabil, es erscheinen sporadisch Testbusfehler. Die Testbussignale sind mit einem Clock 12 MHz überlagert. Erklärung: Ein Zweistufenadapter ist an x) mit einer falschen Nadel-Bauform bestückt. Im BScan-Test darf dieses Signal nicht mit dem Adapter verbunden sein, weil es in den Testbus einkoppelt. Es muss eine kurze Bauform gewählt werden. 10 STMicroelectronics, STM32F103x Testbusfehler: Instruktions- und Datenregister sind länger als im BSDL behauptet. Im Chip gibt es zwei TAP: Gut nachweisbar mit der Boundary Scan Probe. Siehe RM0008, STM32F101xx, STM32F102xx, STM32F103xx, STM32F105xx and STM32F107xx
advanced ARM-based 32-bit MCUs; Abschnitt STM32F10xxx JTAG TAP connection Lösung: Cortex-M3 muss in die Scankette eingefügt werden. IR=5 Bit, BSReg=1 Bit, IDCode: 0x3BA00477
Fragenkatalog, Index, Hyperlinks Fragenkatalog Fehlerbild Fehlermöglichkeit 1 Testbusfehler ist konstant Testbuskabel System-Reset aktiv /TRST nicht angeschlossen Compliance Pattern nicht erfüllt 2 Testbusfehler tritt bei bestimmten Tests auf Prüfung auf Überstrom; Datenbasis des Boardes prüfen, evtl. fehlerhaftes / falsches Modell für BScan IC oder Non-BScan IC Es gibt einen Ground Bounce Effekt Einstellungen zum Testgenerator anpassen 3 Es gibt eine TCK-Frequenz- Abhängigkeit 4 ADYCS Einstellung führen nicht zu Verbesserungen 5 Testbusfehler nur im EXTEST Mode 6 Testbusfehler im Intercon; das verursachende DRSHIFT scheint nicht stabil zu sein im Schrittbetrieb (Debugger) erscheint der Fehler früher 7 Was passiert, wenn BScan Pins am Testbus angeschlossen sind? Fehlerhaftes Board; hoher Strom bei Kurzschlüssen ADYCS Einstellung nicht optimiert Testbus nicht richtig abgeschlossen GND auf dem TAP Kabel bzw. Anschluss nicht optimal Der Leitungsabschluss ist mangelhaft; evtl. Leitungsreflexionen; Siehe 2 BScan schaltet eine Board-interne Versorgungsspannung ab; die Spannung bricht nicht sofort zusammen Stromaufnahme prüfen Diese Pins werden in der Regel automatisch von CASCON erkannt und im Tristate gehalten. Ihnen wird keine Drive-Funktion zugewiesen. 8 Testbusfehler nur im INFRA-Test Möglicherweise ist ein BScan IC mit IDCODE Register nicht Standard-konform und es wird default nicht das ID-Code Register selektiert. Abhilfe: IDCode-Instruktion laden.
FAQs Kann man den vollen Bereich, der mit PASS beim TCK Check-up ermittelt wurde, nutzen? Welche TCK Frequenz ist bei welchen Executables sinnvoll? Wann macht es Sinn, einen Speed Grade B oder Speed Grade C einzusetzen? Warum erscheint bei Testbusfehler oft Diagnose durch IRSHIFT? Obwohl im Testprogramm nur ein DRSHIFT ausgeführt wird, wird im Falle eines Testbusfehlers auch ein IRSHIFT ausgegeben. Wie verhält sich ein SFX-Controller mit dem Speed Grade A bezüglich ADYCS? Warum wird eine Treiber-Änderung das Messergebnis erst im nächsten Schritt sichtbar? Wie kann man prüfen, ob das TDO Pin tristate oder aktiv ist? Woran liegt es, dass beim IRSHIFT alle Ics gleichzeitig..01b am TDO liefern? Wie kann man Ground Bounce Probleme umgehen bzw. beheben? Thema: TAP Verbindungen über Backplane Situation: 8 gleiche Boards mit je 3 Boundary Scan FPGAs werden zusammen im BScan Test angesteuert, um Verbindungen über die Backplane zu testen. Verschiedene Kabel verbinden die Boards, damit entsteht eine lange Boundary Scan Kette. Frage: Wie wird TCK am besten verlegt? Nicht wirklich. Im Testprogramm wird nur ein IRSHIFT ausgeführt. Im Extest Mode und bei DRSHIFT kann es Abweichungen geben. Gehen Sie mit der maximalen TCK etwa 3 MHz nach unten. Infra, Intercon, RAM Intercon, Cluster, SVF: 1 3 MHz oder höher. Hohe TCK Frequenzen beim Intercon können dazu führen, dass viele Pull-Widerstände als fehlerhaft gemeldet werden. RAM mit vielen DRSHIFT (z.b. DDR2-SDRAM) sowie Flash Zugriffe: möglichst hoch, jedoch etwa 3 MHz unterhalb der maximal nutzbaren TCK Sollen mehr als einige Kbyte an Daten in einen (parallelen) FLASH in kurzer Zeit (Sekunden) programmiert werden, dann sollten keine Speed Grade A Controller eingesetzt werden. IRSHIFT ist die einzige Möglichkeit, konstante Vektoren aus den BScan Ics zu lesen. Genauer: Der Capture Wert des IR ist konstant und muss nach Standard..01b für LSB haben. So können Unterbrechungen an TDI und TDO festgestellt werden. Das ist ein automatisches Element in CASCON. Das IRSHIFT kann helfen, den möglichen Fehler-Ort zu diagnostizieren. Auch beim Speedgrade A greift die ADYCS Funktion. Capture findet vor Shift und Update danach statt. Daher erhält der Controller erst mit dem darauffolgenden DRSHIFT das Messergebnis Hochohmiger Spannungsteiler mit 2x 10 kohm nach GND und VCC: ~0V / ½ VCC / ~VCC; DMM oder Oszi BScan Probe: LEDs zeigen Zustand direkt an Da alle Ics mit dem gleichen TCK und TMS versorgt werden, befinden sie sich immer im gleichen TAP-Zustand. Beim Shift-IR TAP Zustand werden also an allen Ics gleichzeitig beginnend mit dem LSB die Capture-Werte der Instruktions- Register ausgetaktet. Und diese sind nach Standard..01b. CASCON bietet in den Generier-Optionen die Möglichkeit, die Anzahl gleichzeitig schaltender Ausgänge zu begrenzen und auf mehrere DrShift aufzuteilen Ideale Situation: Alle Signale, die vom Controller kommen, haben identische Verzögerung. Der Betrag der Verzögerung ist unwichtig. Wichtig ist, dass die BScan Ics untereinander synchronisieren können. Das ist garantiert, solange keine wesentliche Verzögerung zwischen den Ics im Sinne TCK trifft zu früh ein besteht. Das TDI des Controllers kann wie das TDI eines BScan IC gesehen werden. Normalerweise würde ein Synchronisierungs- Problem geben, weil es das Controller-interne TCK benutzt. Eben das wird mittels ADYCS kompensiert. Schlussfolgerung: Buffer auf der Backplane sind gut für die Signalqualität. Solange das Delay für die Signale gleich ist, gibt es keine Nachteile. Das einzig Kritische ist die Verzögerung des letzten TDO eines
Was ist die Ursache, dass bei einem Testbusfehler im Debugger der Test nicht wiederholt werden kann? Boardes, welches mit dem TDI des nächsten Boardes verbunden ist. Man soll hier keine Buffer verwenden. Die Verzögerung könnte kompensiert werden, wenn TCK und TMS in gleicher Weise durch Buffer verzögert würden. Hier liegt die wirkliche Grenze, aber die Verzögerung kann berechnet / gemessen werden. Diese Einstellungen sind wahrscheinlich unpassend. Stellen Sie sicher, dass diese Einstellung verwendet wird:
Typische Arbeitsfehler und Missverständnisse Der Testbusfehler-Bericht wird nicht genau gelesen. Er zeigt jedoch oft auf einen bestimmten Fehler- Ort und gibt außerdem Empfehlungen zur Fehlersuche. Testbus Kabel GND nur an einer Seite angeschlossen; es handelt sich nicht um eine Abschirmung, sondern GND muss den Treiberstrom zurückleiten Kabel-Design: TDI mit TDO vertauscht Testbuskabel kein twisted Pair oder Flachband-Kabel mit GND-Signal-GND-Signal Schema GND Anschluss auf der UUT-Seite liegen nicht in Nachbarschaft zum TCK Anschluss; ist die Entfernung zu groß, wird der Rückstrom mit anderen Strömen überlagert Testbus-Signale an UUT-Seite nicht abgeschlossen; das ergibt Leitungsreflexion, die zu Über- und Unterschwingern führt Mehr als 5 BScan ICs parallel an TCK und TMS; Spikes in den Flanken können die Folge sein Ground-Bounce Problem nicht beachtet; Gefahr von Testbusfehlern während des Tests TCK ist zu nahe an der maximal nutzbaren (sporadische Testbusfehler, Pseudo-Datenfehler) Testbyte de-aktiviert (ein möglicher Testbusfehler wird nicht erkannt und führt zu einer falschen Diagnose an einer Vielzahl von Netzen im Intercon-, RAM-Intercon- und Cluster-Test) Testbyte de-aktiviert, um INFRA Test einen Teilerfolg zu erreichen; das Ergebnis ist wertlos BScan aktiviert Systemreset auf dem Board BScan schaltet Power Supply auf dem Board BScan schaltet Treiber des Testbus Treiber arbeiten gegeneinander; Defekt oder Datenaufbereitung falsch (Library Modell, Bestückungsvarianten, CAD Daten, Extended Generator Settings) Testbusleitungen werden durch BScan Pins angesteuert Nicht genügend Wartezeit nach dem Zuschalten der Versorgungsspannung Annahme, eine niedrige TCK Frequenz kompensiert ein schlechtes Testbuskabel-Design; Überschwinger und Unterschwinger sind nicht von der Frequenz abhängig Das Programm TCK Check-up wird für einen nicht verwendetem (im CON nicht beschriebenen) TAP verwendet; dabei ist das Ergebnis immer PASS CON wurde manuell erstellt und die Reihenfolge falsch beschrieben. Möglicherweise bringt INFRA PASS, insbesondere, wenn keine IDCode Register vorhanden sind oder wenn identische Devices in der Kette sind. Große Anzahl fehlerhafter Netze im Intercon; sogar Pins, welche an GND oder VCC liegen, zeigen den falschen Pegel; häufig Testbusfehler wegen Treiberkonflikten falsche Test-Bus Spannungseinstellungen am TAP Transceiver können zu High/Low Fehlern am Testbus führen Ignorieren des Testbusfehlers, weil man ja nur die Messergebnisse von der UUT braucht
Begriffe und Abkürzungen TAP TAP Controller TAP State Ground-Bounce TCK TMS TDI TDO TRST ADYCS CASLAN SVF JAM/STAPL Abschluss Testbyte Fan-Out Compliance Pattern Scan Router BSDL IR CON LSB UUT Test Access Port, das Interface für den Testbus TAP Steuerwerk im BScan IC Zustand des TAP Controllers Anstieg des GND Potentials im Chip durch gleichzeitigen Schaltens vieler Outputs; der TAP Controller kann die Synchronisation verlieren Testbus-Signal: Test Clock Testbus-Signal: Test Mode Select Testbus-Signal: Test Data In Testbus-Signal: Test Data Out Testbus-Signal: Test Reset Active Delay Compensation; CASCON Eigenschaft, Signal-Verzögerungen auf dem Testbus zu kompensieren CASCON Programmiersprache Serial Vector Format, einfaches Vektorbeschreibungsformat, kein Standard einfaches Vektorbeschreibungsformat, etwas flexibler als SVF, standardisiert Hier: impedanzgerechter Leitungsabschluss Prüfbyte zum Verifizieren der Kettenlänge; CASCON Eigenschaft Treiberparameter; definiert die maximale Zahl der Inputs, die noch sicher getrieben werden können Randbedingungen zur Erfüllung des BScan-Zuganges in BScan ICs; typisch für Umschalten zwischen Emulation/Debuggen und BScan Test bei Prozessoren, da das JTAG Interface für beide Anwendungen genutzt wird ICs zum Aufteilen von Scan-Pfaden Boundary Scan Description Language (File) Instruktionsregister Scan Path Configuration File; CASCON File; das erste genannte IC ist mit seinem TDO mit dem TDI des Controllers verbunden. Least Significant Bit, das niederwertigste Bit Unit-Under-Test; der Prüfling Sie benötigen weitere Hilfe? Wenn die bisherigen Arbeitsschritte keinen Erfolg bringen, benötigen Sie den Support von Göpel electronic. Ein Applikations-Ingenieur wird Ihnen dann behilflich sein. Nutzen Sie dabei bscan_support@goepel.com. Ausgeschlossen von diesem Support ist jedoch die Beschaffung eines BSDL Files. Hierzu müssen Sie auf jeden Fall den Chiphersteller kontaktieren.
Anlagen Testprogramm TCK Check Up_1TAP Note: Starting from CASCON 4.6.0, you need CON depending versions of the test program. The version below reflects version for TAP1 only. -- ------------------------------------------------------------------- -- -- Caslan File -- -- Name : TCK Check Up.CAS -- Date : 15.04.2005 -- Author : vieweg -- -- ------------------------------------------------------------------- -- Version Date Change -- 1.0 15.04.2005 Creation -- 1.1 13.12.2006 Update compressed output format -- 1.2 21.12.2006 Update TAP selection -- 1.4 01.03.2013 Update TAP selection according to CON file -- -- ------------------------------------------------------------------- PROGRAM 'TCK Check UP'; VAR v_tck v_2 : INT; : INT; v_3 : 16; vsel : 16; failflag : 1; vloopcnt LABEL NewSelect; : INT; PROC ptap3; -- procedure keyword 'PROC' and name 'ProcName' BEGIN -- place procedure code between 'begin' and 'end;' WRITE (' '); FOR v_tck := 1 TO 79 DO --20 MHz -- FOR v_tck := 1 TO 39 DO --10 MHz TCK v_tck; IRSHIFT; IF failflag ==1 THEN WRITE ('F'); LD failflag, 0; ELSE WRITE ('.'); TAPRESET; PROC p_tap_test; BEGIN; WRITELN (' 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20'); WRITELN ('........................................................... '); WRITE (' '); FOR v_2 := 1 TO 79 DO --20 MHz TCK v_2; IRSHIFT; IF failflag ==1 THEN WRITE ('F'); LD failflag, 0; ELSE WRITE ('.');
WRITELN (' 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40'); WRITELN ('............................................................ '); WRITE (' '); FOR v_2 := 80 TO 159 DO --40 MHz TCK v_2; IRSHIFT; IF failflag ==1 THEN WRITE ('F'); LD failflag, 0; ELSE WRITE ('.'); WRITELN (' 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60'); WRITELN ('............................................................ '); WRITE (' '); FOR v_2 := 160 TO 239 DO --60 MHz TCK v_2; IRSHIFT; IF failflag ==1 THEN WRITE ('F'); LD failflag, 0; ELSE WRITE ('.'); WRITELN (' 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80'); WRITELN ('............................................................ '); WRITE (' '); FOR v_2 := 240 TO 319 DO --80 MHz TCK v_2; IRSHIFT; IF failflag ==1 THEN WRITE ('F'); LD failflag, 0; ELSE WRITE ('.'); PROC ploop20mhz; BEGIN; WRITELN (' 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20'); WRITELN ('........................................................... '); LOOP vloopcnt DO CALL ptap3; WRITELN ('........................................................... '); WRITELN (' 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20'); PROC pactionselect; BEGIN; READSELECTION ('Action select', vsel, '1 x 80 MHz', '100 x 20 MHz', '1000 x 20 MHz', 'Exit'); SWITCH vsel