Besteht ein Risiko für die HW, eine eingebettete Software zu debuggen, wenn die JTAG-Integrität schlecht ist?

Es ist unwahrscheinlich, dass Sie das Teil beschädigen, aber Sie können die Verbindung möglicherweise nicht erfolgreich oder sinnvoll zum Debuggen des Geräts verwenden. Sie werden nie sicher sein, dass Sie einen Softwarefehler oder einen Fehler Ihres Debuggers sehen, da einige Fehlermodi in jedem Fall zum Ausfall der Debug-Schnittstelle führen können.

Probleme mit der Signalintegrität können oft durch Reduzieren der JTAG-Taktrate gelöst werden. Dies wirkt sich auf die Leistung beim Laden von Software und bei großen Speicherauszügen oder Datenüberwachungen aus, bleibt jedoch für einfaches Breakpoint- und Stepping-Debuggen auch bei relativ niedrigen Frequenzen verwendbar. Wenn Sie bereits einen Fehler von 60 % sehen, wird es Ihnen nicht schlechter gehen, beispielsweise von 10 MHz auf 4 MHz zu reduzieren, und es kann sein, dass er auf Null abfällt. Ich schlage vor, 1 MHz als Ausgangspunkt zu versuchen. Wenn die Leistung nicht zufriedenstellend ist, können Sie versuchen, sie schrittweise zu erhöhen, um die maximale fehlerfreie Rate zu bestimmen, und wenn Sie weiterhin Fehler erhalten, reduzieren Sie sie weiter.

Im Allgemeinen sollte das JTAG-Kabel so kurz wie möglich sein (<20 cm als Richtlinie) – vorzugsweise das Originalkabel des Sondenherstellers ohne Adapter oder Verlängerungen.

Als diese Frage auf SO gepostet wurde, haben Sie einen Kommentar hinzugefügt, dass die Sonde ein Blackhawk USB200 war – das Produkt verfügt über einen optionalen Isolationsadapter für raue Umgebungen, um Probleme mit Erdschleifen zu vermeiden. Das kann Ihr Problem vollständig lösen.

Sind Sie schließlich sicher, dass die Fehlerrate auf Rauschen zurückzuführen ist? Ein häufiger Fehler ist es beispielsweise, auf die für JTAG verwendeten Pins als GPIO in der Software zuzugreifen.

Hinzufügen meiner 2 Cent. Kommentieren nicht möglich!

Wir hatten ein ähnliches Problem mit demselben Ziel (C2000). Sehr oft wurde das Gerät getrennt und wir mussten die IDE neu starten und den Code zum Debuggen erneut flashen. Wir haben TI kontaktiert und den folgenden Vorschlag erhalten.

1) Verwenden Sie einen digitalen Isolator wie diesen zwischen dem Debugger und dem Ziel.

2) Reduzieren Sie die JTAG-Kabellänge. Typischerweise ist unsere weniger als 5 cm.

Es hat gut funktioniert.

Bearbeiten: Clifford hat bereits auf diese Dinge hingewiesen. Ich füge nur meine Erfahrung hinzu.

Es kann absolut Hardware beschädigen.

Angenommen, Ihre IR-Verschiebung wird auf einer MCU oder einem FPGA beschädigt und Sie laden versehentlich EXTEST oder geben eine IEEE 1532 ISC-Anweisung ein, und Sie haben keine sicheren Werte in den BSR-Zellen festgelegt. Jeder BSR-Pin auf diesem Gerät bestätigt sofort den Zustand, der sich gerade in diesen Zellen befindet.

Wenn Sie beispielsweise einige Geräte mit Leistungselektronik haben und kein externer Schutz vorhanden ist, können Sie beide MOSFETs in einem Schaltregler auslösen und die Spannung direkt auf GND kurzschließen. Ich habe das mehrfach erlebt. EXTEST ist wahrscheinlich die riskanteste Anweisung, die in der Spezifikation definiert ist.

Wenn Sie Ihrem JTAG-Setup nicht vertrauen können, würde ich anhalten und das Problem beheben, bevor Sie fortfahren. Denken Sie auch außerhalb von Hardwareschäden an die ganze Engineering-Zeit, die Sie verschwenden werden, um Heisenbugs zu jagen, die sich in einer DR-Schicht hin und wieder als etwas ausgefallen herausstellten.

Sehen Sie sich im Grunde Ihr Design an und überlegen Sie, was passiert, wenn jeder Pin auf einem JTAG-Gerät in einen unbekannten Zustand springt (oder alle 0 oder alle 1) – die Chancen stehen gut, dass Sie mit dem Ergebnis nicht zufrieden sein werden.

Andere Dinge, die ich in der Vergangenheit aufgrund schlechter JTAG-Integrität getan habe, sind das versehentliche Auslösen von Sicherheitssicherungen und ähnlichem. Dies würde das Teil mauern und es erfordern, es zu ersetzen. JTAG hat konstruktionsbedingt keine Integritätsprüfung oder Fehlerkorrektur – es ist konstruktionsbedingt einer der einfachsten möglichen Busse.

Während eine direkte physische Beschädigung des Hardwaregeräts unwahrscheinlich erscheint, besteht eine sehr reale Wahrscheinlichkeit, dass eine verrauschte JTAG-Verbindung dazu führt, dass eine solche Sicherung fälschlicherweise so eingestellt wird, dass eine solche Sicherung fälschlicherweise so eingestellt wird, dass eine solche Sicherung fälschlicherweise so eingestellt wird, dass sie gerendert wird, wenn ein Gerät irgendeine Art von einmal beschreibbaren Konfigurationssicherungen enthält der Chip dauerhaft unbrauchbar. Darüber hinaus werden viele Prozessoren auf eine Weise verwendet, die Schaltkreisschäden an der CPU oder anderer Hardware verursachen könnte, wenn die I/O-Pins auf fehlerhafte Bedingungen gesetzt würden.

Grundsätzlich würde ich vermuten, dass eine laute JTAG-Verbindung dazu führen könnte, dass das System fälschlicherweise glaubt, dass Sie ihm die Kombination von Befehlen und Daten geben, die am gefährlichsten wäre. Wenn Sie dem Gerät nichts zuführen, was besonders schädlich wäre, wird nichts beschädigt. Aber wenn es möglich wäre, das Gerät mit dem JTAG absichtlich zu beschädigen, sollte man davon ausgehen, dass ein solcher Schaden auch versehentlich auftreten könnte, es sei denn, man hat systematische Anstrengungen unternommen, um dies zu verhindern.