Echtzeit-Debugging über JTAG / SWJ-DP für ARM Cortex-M-Kernmikrocontroller


    Segger bietet seit einiger Zeit RTT- Technologie (Real Time Terminal) für seine J-Link J-Link-Adapter an. Das Wesentliche ist, dass das Programm auf dem Mikrocontroller Debugging-Informationen vom JTAG / SWJ-DP-Port ausgeben und empfangen kann, wie dies normalerweise über UART erfolgt. Und dann brauchen wir keinen echten Debugging-UART mehr. Darüber hinaus etwas mehr über die Fähigkeiten dieser Technologie.

    Die Möglichkeit, Debugging-Informationen an den JTAG / SWJ-DP-Port auszugeben, wurde implementiert, sobald der Port selbst auf den Mikrocontrollern angezeigt wurde. Hierfür gibt es zwei Möglichkeiten: Verwenden Sie die Semihosting- Technik oder die SWO- Technik ( Serial Wire Output) .

    Mit semihostingführt zur Ersetzung von Eingabe- / Ausgabekanälen von Standarddateivorgängen der Sprache C. Dies ist nicht immer akzeptabel, da Dateivorgänge in der Anwendung möglicherweise bereits für einen anderen Zweck verwendet werden. Außerdem muss Semihosting das Projekt explizit deaktivieren und neu kompilieren, wenn die Release-Version veröffentlicht wird.

    Darüber hinaus bietet Semihosting die langsamste Datenübertragung der hier diskutierten Technologien.

    Die Verwendung von Serial Wire Output ist einfacher als Semihosting, erfordert jedoch die Verwendung eines zusätzlichen SWO-Signals vom JTAG / SWJ-DP-Port und erfordert auch eine Neukompilierung beim Umschalten auf die Release-Version, d. H. Version ohne Anschluss eines Debuggers. Die SWO-Ausgangsfunktionen sind synchron, d.h. Sie erwarten Hafenbereitschaft und haben nicht den notwendigen Determinismus.

    Die Echtzeit-Terminal-Technologie von Segger macht die Ausgabe von Debugging-Informationen über SWJ-DP noch einfacher und bietet die folgenden Annehmlichkeiten :
    • Nur zwei externe Leitungen sind ausreichend - dies sind SW CLK und SW DIO.
    • Der gesamte zusätzliche Code im Mikrocontroller benötigt nicht mehr als 500 Byte. Wenn Sie keine Eingabe verwenden, sind es sogar 300 Byte.
    • Für die Release-Version ist keine Neukompilierung erforderlich. Die Debug-Ausgabefunktionen sind asynchron und beanspruchen praktisch keine Prozessorzeit. Sie haben keine Auswirkungen auf den Programmfortschritt, wenn der Debug-Adapter nicht angeschlossen ist.
    • Die Geschwindigkeit der Debug-E / A ist sehr hoch.
    • Debug-E / A können an jedes Terminalemulatorprogramm eines Drittanbieters umgeleitet werden, das das Telnet-Protokoll unterstützt.
    • Segger bietet kostenlose Dienstprogramme für Terminalemulator, Logger und Telnet-Client für die Verbindung mit einem Mikrocontroller über einen Debug-Adapter, ohne dass IDEs von Drittanbietern mit Debuggern ausgeführt werden müssen.



    Ein Beispiel für die Verwendung von RTT.


    In der obigen Abbildung basiert die Controller-Karte auf dem STM32F745VET6-Chip. Externer Quarz 16 MHz. Die Kernfrequenz beträgt 168 MHz.
    Für den Bootloader war ein Debugging über den CAN-Bus erforderlich. Es ist eine serielle RS232-Schnittstelle mit dem UART verbunden, die jedoch auch für den Bootloader verwendet wird. Die Ausgabe von Debugging-Informationen würde bedeuten, dass die Debugging-Version des Programms im Vergleich zur Release-Version stark geändert wird. Dies ist aus Zeitgründen äußerst unerwünscht.

    Um RTT anzuschließen, wurden die folgenden Schritte ausgeführt:
    1. RTT-Quellcode verwendet ( http://download.segger.com/J-Link/RTT/RTT_Implementation_141217.zip )
    2. Quellen werden entpackt und in das Projektverzeichnis RTT kopiert. Das Projekt selbst wurde im Umfeld von Keil MDK ARM durchgeführt
    3. Quellen sind mit dem Projekt verbunden. Die Dateien SEGGER_RTT.h und SEGGER_RTT_Conf.h wurden zur allgemeinen Liste der Projektheaderdateien hinzugefügt
    4. Zusätzliche Einstellungen wurden in der Datei SEGGER_RTT_Conf.h vorgenommen: Der Wert von BUFFER_SIZE_UP wurde auf 2048 erhöht, der Wert von SEGGER_RTT_PRINTF_BUFFER_SIZE wurde auf 512 erhöht. Die Parameter wurden tatsächlich iteriert, bis die angegebenen Puffer überliefen.
    5. Bearbeiten von Bootloader-Quellen. An allen Stellen von Interesse wurden Aufrufe der Funktion SEGGER_RTT_printf mit den erforderlichen Meldungen eingefügt. Ich habe diese Funktion als die bequemste verwendet, obwohl sie einen erheblichen Stapelverbrauch und eine gewisse Verzögerung bei der Datenkonvertierung mit sich bringt. Aber in meinem Fall war es akzeptabel.
    6. Da das Debuggen auch beim Programmieren von internem Flash erforderlich war, habe ich den RTT-Code in den RAM des Mikrocontrollers übertragen. Zu diesem Zweck hat RTT in allen beiden Quelldateien eine Direktive eingeführt
      #pragma arm section code = "CODE_IN_RAM",

      und in der Linker-Datei .sct wurde dieser Bereich wie folgt definiert:
      RW_IRAM1 0x20000000 0x00010000
      {
      .ANY (+ RW + ZI)
      * (CODE_IN_RAM)
      }
    7. Definierte absolute Strukturadresse für die Direktive SEGGER_RTT_CB als Direktive
      statisch SEGGER_RTT_CB _SEGGER_RTT __attribute __ ((at (0x20000000)))
    8. Das Projekt wurde kompiliert. Nach der Kompilierung stellte sich heraus, dass der RTT-Code im RAM 400 Byte ohne Optimierung benötigte.
    9. Ich habe den Dienstprogrammaufruf JLinkRTTViewer.exe in das Keil IDE-Tool-Menü eingefügt
    10. Da ich TeraTerm lieber als Termemulator verwende, habe ich einen Aufruf in das Menü eingefügt. Die Anrufleitung lautet wie folgt:
      "C: / Programme (x86) /teraterm/ttermpro.exe" / T = 1 Telnet: // localhost: 19021 / X = 0 / Y = 0 / W = "J-Link RTT"


    Durchsatz


    Es schien interessant zu sein, mit welcher Geschwindigkeit Informationen über einen Debugging-Adapter mit RTT an den Terminalemulator ausgegeben werden. Wellenformen wurden aus den SW SLK- und SW DIO-Signalen entnommen.

    Es stellte sich heraus, dass J-Link Abfragen mit einer Frequenz von etwa 40 ms verwendet. Für die Datenübertragung werden nicht mehr als 50% dieses Zeitraums verwendet. In einem über einen Zeitraum übertragenen Datenblock belegen Pakete, die nützliche Daten enthalten, ebenfalls nicht mehr als 50% der Zeit. Pakete enthalten nicht mehr als 3 Byte nützliche Daten. Drei Bytes nützlicher Daten in einem Paket belegen ebenfalls nicht mehr als 50% seiner Länge. Insgesamt erhalten wir: 0,5 * 0,5 * 0,5 = 0,125, d.h. 12,5% der Bandbreite des SW-Kanals werden zur Übertragung der Debug-Ausgabe verwendet.

    Die Kanalfrequenz über 4 MHz in J-Link konnte unter keinen Einstellungen erhöht werden. Dies bedeutet, dass wir eine maximale Übertragungsrate von 4 Mbit / s haben. Von diesen sind nur 4 · 0,125 = 0,5, d.h. 500 Kbit / s können bestenfalls zum Debuggen der Ausgabe verwendet werden. Dies ist natürlich nicht viel im Vergleich zum tatsächlichen Debugging-UART, der mit einer Geschwindigkeit von mehreren Mbit / s übertragen kann, aber alles hat einen Preis.

    Jetzt auch beliebt: