Erkennung der JTAG-Pinbelegung

Sie können die „optionalen“ Pins wahrscheinlich ignorieren, mit Ausnahme von RTCK. Es sollte kein Debug-Szenario geben, in dem diese Pins erforderlich sind, es sei denn, Ihr Teil hat den JTAG-Port deaktiviert, indem er in einem „Reset“-Zustand abgebunden ist. Wenn das Ziel diese optionalen Pins implementiert, ist es wahrscheinlich, dass die PCB sie fest verdrahtet, als sie auf einem Steckverbinder freizulegen. Wenn Sie einen Anschluss als Kandidaten-JTAG-Port identifiziert haben, kann dieser auch eine 3v3-Referenz (Zielversorgungsschiene) bereitstellen, die Ihr Tastkopf verwenden soll (und kann wahrscheinlich auch ignoriert werden).

RTCK kann auf einem alten Arm-Ziel vorhanden sein, alles ARM11 und früher. Dies ist eine abgetastete und verzögerte Version der TCK-Eingabe, neu synchronisiert mit der internen Kernuhr. Wenn RTCK verwendet wird, müssen Sie Ihr JTAG langsam ausführen oder auf die RTCK-Flanken warten. Alles, was den CoreSight-DAP verwendet, verwendet kein RTCK (es könnte möglicherweise als Loopback von TCK verdrahtet werden, erfüllt jedoch keinen Zweck).

Denken Sie daran, dass 2-polige Serial-Wire-Debug-Ports jetzt üblich sind. Sie benötigen eine andere Sequenz, um diese zu erkennen (in der Größenordnung von 100 Bits pro Pin, die als Daten getestet werden). Es gibt in diesem Fall kein einfaches FSM wie bei JTAG.

Mir ist aufgefallen, dass die aktuelle Open-OCD-Dokumentation darauf hinweist, dass die JTAG-Taktgeschwindigkeit auf ~CPU/6 begrenzt ist. Dies gilt nur für die älteren ARM-Kerne, bei denen der RTAG TAP direkt mit dem Prozessor verbunden ist. Bei jedem Prozessor mit einem CoreSight DAP ist der Debug-Takt vollständig asynchron zu den internen Takten und kann sogar mit JTAG/SW-Takt schneller als der Prozessor laufen.

Siehe hier für die Standardanschlüsse - Sie finden möglicherweise auch eine Versorgung, eine Zielspannungsreferenz und einen Zielfunktions-Reset - aber dies hängt vom Plan des Designers für das Debuggen der Platine ab.

Ich lerne gerade, aber soweit ich verstanden habe, brauchen Sie zuerst die Pinbelegung Ihres eigenen Arduino. Zum Beispiel habe ich in meinem Fall Arduino Nano.

Wie Sie sehen können, gibt es Zahlen in Lila, die Sie verwenden können. So viele Pins Sie in Ihrem Arduino zur Verfügung haben, mehr Pins können Sie gleichzeitig in Ihrem Zielboard testen.

Sie können also einen Code wie diesen schreiben:

byte      pins[] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 11, 12, 13, 14, 15, 16, 17, 18, 19 };

char * pinnames[] = { "DIG_0 ", "DIG_1 ", "DIG_2", "DIG_3", "DIG_4", "DIG_5", "DIG_6", "DIG_7", "DIG_8", "DIG_9", "DIG_10", "DIG_11", "DIG_12", "DIG_13", "DIG_14", "DIG_15", "DIG_16", "DIG_17", "DIG_18", "DIG_19" };

Allerdings gibt es dabei ein Problem. Die Anzahl der Kombinationen ist riesig und wahrscheinlich haben Sie im Ziel eine Vorstellung davon, welche 6 Pins die JTAG-Schnittstelle sein können.

So können Sie mit der Mindestzahl vereinfachen:

byte      pins[] = { 0, 1, 2, 3, 4, 5};

char * pinnames[] = { "DIG_0 ", "DIG_1 ", "DIG_2", "DIG_3", "DIG_4", "DIG_5" };

In beiden Fällen müssen Sie alle im Arduino registrierten Pins an einen der verdächtigen Pins im Ziel anschließen (in den ersten Fällen sind möglicherweise einige der 20 Pins leer).

Dann müssen Sie eine Verbindung zum seriellen Port zum JTAGEnum-Programm herstellen und nach dem Scannen (Befehl s) sollten Sie die Ergebnisse der Tests erhalten (falls vorhanden).

Wenn Sie einen JTAG gefunden haben, teilt Ihnen das Programm mit, welche Pins in Ihrem Arduino mit den identifizierten JTAG-Pins übereinstimmen.

Zum Beispiel:

GEFUNDEN! tck:DIG_0 tms:DIG_1 tdo:DIG_2 tdi:DIG_3

So können Sie der DIG_0 folgen, um zu wissen, welche tck im Ziel ist, ...

Es tut mir leid, wenn ich mich nicht sehr gut erklären kann, und ich hoffe, das kann helfen