Jeffrey Cross
Jeffrey Cross

Erste Schritte mit In-Circuit-Debugging

Wenn Sie etwas Kompliziertes herstellen (oder demontieren), könnten Sie sich nach einer besseren Sicht nach innen sehnen. Ein Oszilloskop oder Logikanalysator kann ein wichtiges Werkzeug für die digitale Elektronik sein und auch für Embedded-Software überraschend nützlich sein. Ihr Code kann auch über Meldungen helfen, die in einer Datei oder einem seriellen Port protokolliert werden. Manchmal benötigen Sie jedoch wirklich eine interaktive Ansicht der Interna Ihres Programms. Bei einem eingebetteten System bedeutet dies, dass Sie einen In-Circuit-Debugger (ICD) benötigen.

Einige von Ihnen kennen das Debuggen auf Quellenebene aus anderen Kontexten, beispielsweise das Debuggen von Desktopanwendungen in Xcode oder Visual Studio, die Verwendung von Haltepunkten und Einzelschrittfunktionen für Skripts in der Konsole eines Webbrowsers oder die Verwendung eines eigenständigen Debugger wie dem GNU-Debugger WinDbg oder LLDB. Wenn Sie jedoch eher an Arduino gewöhnt sind, ist dieses Tool möglicherweise neu für Sie.

Debugger bezieht sich im Allgemeinen auf ein System, das aus Debugging-Software auf Ihrem PC besteht, möglicherweise Software auf dem von Ihnen getesteten Chip und normalerweise etwas Hardware innerhalb und außerhalb des Chips. Bei vielen Mikrocontrollern ist ein On-Chip-Debugger (OCD) in das Silizium eingebettet.

Ein Debugger kann eine Zeile oder einen Befehl gleichzeitig durchlaufen, während er den Inhalt von Variablen anzeigt, und er kann den Speicher anzeigen oder bearbeiten. Sie können Ihr Programm mit voller Geschwindigkeit ausführen, bis es einen Haltepunkt erreicht - eine absichtliche Pause in Ihrem Code -, an der es anhält und der Debugger fortgesetzt wird. Wenn ein Debugger angeschlossen ist, können Sie normalerweise mit den Peripheriegeräten eines Prozessors interagieren, Programme in den Flash-Speicher laden und den Flash-Inhalt lesen (sofern keine Schutzvorrichtungen vorhanden sind, um dies zu verhindern!).

Was ist ein Debug-Server?

Die Debugger-App auf Ihrem PC speichert eine detaillierte Speicherzuordnung für Ihren Code. Sie benötigen jedoch auch Hardware (oder Software) auf Ihrem Mikrocontroller, um Speicher lesen und schreiben zu können, Haltepunkte abzufangen und Anweisungen kontrolliert auszuführen. Eine Lösung ist ein Debug-Server.

Der GNU Debugger (GDB) definiert ein besonders einfaches Serverprotokoll für die Verwendung über einen seriellen Anschluss oder ein Netzwerk, einschließlich localhost. Implementierungen dieses gdb-Servers existieren für verschiedene Betriebssysteme. Normalerweise war dies nur eine Softwarekomponente, aber das Protokoll wird jetzt allgemein als Gateway für Hardwaregeräte oder Emulatoren verwendet.

Ebenso reichen Ihre IDE-Optionen jetzt weit über eine grundlegende GDB-Befehlszeile hinaus. Tools wie Eclipse, Visual Studio Code und IDA Pro unterstützen dasselbe GDB-Protokoll.

Hardware-Debug-Ports

Es wäre praktisch, wenn die in Silizium integrierten Debugging-Funktionen direkt mit dem GDB-Protokoll kompatibel wären, die OCDs jedoch für minimale Kosten und Auswirkungen auf das gesamte Prozessordesign optimiert sind. Normalerweise wird das Debugging über denselben Port bereitgestellt, der für die Programmierung des Flash-Speichers verwendet wird. Einige Chips verwenden herstellerspezifische Protokolle, es sind jedoch zwei Industriestandards zu beachten: JTAG und SWD.

Was auch immer das Protokoll ist, einige Hardware wird benötigt, um wieder in USB umzuwandeln. Eine Vielzahl von Adaptern kann über die Open-Source-OpenOCD-Software als Debug-Server verwendet werden. Auch für Hookups, die Sie bereits haben, wie Raspberry Pi GPIOs oder einen seriellen FTDI-Breakout. Die Black Magic Probe (siehe „Bug Squashers“, rechts) ist ein offenes Hardwaregerät, das den Debug-Server in Firmware implementiert und einen virtuellen seriellen Port bietet, den Sie direkt an GDB anschließen.

JTAG: Der ursprüngliche Standard - es ist kein guter Name. Wie JPEG sagt es nicht aus, was der Standard tut, nur wer ihn entworfen hat: die Joint Test Action Group. Es wurde Mitte bis Ende der 1980er Jahre entworfen und 1990 standardisiert, als Reaktion auf komplexe Leiterplattenbaugruppen, die zu schwierig für automatische Tests waren.

Bei dem JTAG-Standard (IEEE 1149.1) handelt es sich elektrisch um eine Reihe von Schieberegistern, die zwischen den Geräten verkettet werden können. Sie können Ihren Debugger direkt an ein einzelnes Gerät oder an eine Kette von Geräten innerhalb eines einzelnen Chips oder über mehrere Chips anschließen. JTAG sieht äußerlich wie SPI aus, mit einem gemeinsamen Takt und Einweg-Dateneingangs- und -ausgangspins. Dann wird jedoch ein Test Mode Select (TMS) -Pin angezeigt. Ist es ein Chip-Select? Nein. Hier beginnt JTAG besonders schwach zu werden. Es ist tatsächlich ein kleines Muster, das eine durch den Standard spezifizierte Zustandsmaschine antreibt, auf der die Chiphersteller ihre eigenen JTAG-Zustandsmaschinen erstellen.

Der JTAG-Standard legt Zustände für die Auswahl eines Geräts und das Lesen seines 32-Bit-ID-Codes fest. und JTAGs Boundary-Scan-Protokolladressen auf einem IC für die elektrische Prüfung von bestückten Leiterplatten. Darüber hinaus wird es gerätespezifisch: FPGAs und Prozessoren und Speicher verfügen jeweils über eigene Protokolle. Diese Fragmentierung spiegelt die Fragmentierung wider, die Sie im gesamten eingebetteten Werkzeugbereich sehen!

Zumindest bei modernen ARM-Prozessoren tun uns die Standards einen Gefallen. Die Spezifikation für die ARM-Debugschnittstelle beschreibt einen Standard-JTAG-Debugport, mit dem auf Speicher, Peripheriegeräte und den CPU-Status zugegriffen werden kann. Von dort können speicherzugeordnete Register Haltepunkte modifizieren und die CPU steuern.

SWD: Der Neuankömmling - Als ARM eine Methode für den Zugriff auf Speicher- und CPU-Debugfunktionen über JTAG standardisierte, nutzte er die Gelegenheit, ein neues alternatives Protokoll zu entwickeln: Serial Wire Debug (SWD), das einen einzigen bidirektionalen Daten-Pin und ein modernisiertes Paket verwendet Struktur. Aufgrund der reduzierten Pin-Anzahl eignet sich SWD ideal für kleinere Embedded-Prozessoren wie die beliebte ARM Cortex-M-Serie, und es kann Pins mit JTAG teilen, wenn der Prozessor beide Optionen unterstützt.

Das ist ungefähr alles, was Sie über SWD selbst wissen müssen, wenn Sie nur den Debug-Port auf einem Prozessor anschließen und High-Level-Tools wie GDB ausführen möchten. Die Details zur Konfiguration von OpenOCD, GDB und Ihres spezifischen Debug-Adapters unterscheiden sich je nach Plattform. Daher möchten Sie die in OpenOCD enthaltene Konfigurationsdatei suchen, die als Ausgangspunkt Ihrer Situation am ehesten entspricht.

Wenn Sie wissen möchten, wie das Debuggen und sogar die Verarbeitung von Prozessoren auf einer tieferen Ebene funktionieren, ist der Debug-Port ein hervorragender Ort, um mit dem Graben zu beginnen!

  • »Weitere Informationen zum Debuggen von ARM:
  • »Ich habe einen einfachen webbasierten SWD-Speicherbrowser für den ESP8266 und einen Artikel in PoC || GTFO 10.5 geschrieben.
  • »Finden Sie eine umfassendere Open Source-Implementierung von SWD, testen Sie die Black Magic Probe oder Free-DAP.

Aktie

Leave A Comment