Share via


Debuggen von Partneranwendungen

  1. Stellen Sie sicher, dass Ihr Gerät über USB mit Ihrem PC verbunden ist. Wählen Sie im Menü Startelement festlegen die Option Azure Sphere-App (Alle Kerne) aus, wobei Azure Sphere-App der Name Ihres Projekts der obersten Ebene ist, oder drücken Sie F5.

    Schaltfläche

  2. Wenn Sie aufgefordert werden, das Projekt zu erstellen, wählen Sie Ja aus. Visual Studio kompiliert die Partneranwendungen, erstellt Imagepakete, überlädt sie quer auf das Board und startet sie im Debugmodus. Querladen bedeutet, dass die Anwendungen direkt vom PC über eine kabelgebundene Verbindung und nicht über die Cloud bereitgestellt werden.

    Notieren Sie sich die Pfade in der Ausgabe Anzeigen>ausgabe>von: Buildausgabe , die den Speicherort der Ausgabeimagepakete auf Ihrem PC angibt. Wenn Sie bereit sind, eine Bereitstellung zu erstellen, müssen Sie die Pfade zu den Imagepaketen kennen.

  3. Standardmäßig wird im Ausgabefenster die Ausgabe der Geräteausgabe angezeigt. Wählen Sie zum Anzeigen von Meldungen aus dem Debugger im Dropdownmenü Ausgabe anzeigen von: die Option Debuggen aus. Sie können auch die Programmdemontage, Die Registrierungen oder den Arbeitsspeicher über das Menü Debuggen> vonFenstern überprüfen.

Wenn Sie über zwei RTApps verfügen, stellen Sie sicher, dass beide als Partner-Apps in der Datei launch.vs.json der obersten Ebene aufgeführt sind.

Verwenden Sie den Visual Studio-Debugger , um Haltepunkte festzulegen, die Anwendung anzuhalten, zu überspringen, neu zu starten oder zu beenden.

Während sie an einem Haltepunkt in Ihrem C-Quellcode beendet wurde, können Sie ein Disassembly-Fenster öffnen, in dem die aktuelle Adresse, der Assembler mnemonisch für den aktuellen Befehl und Informationen wie die beteiligten Register oder der ausgeführte Quellcodebefehl angezeigt werden.

So öffnen Sie das Fenster Disassemblierung :

  1. Stellen Sie sicher, dass die C-Codequelldatei, die den Haltepunkt enthält, in Visual Studio geöffnet ist.
  2. Wählen Sie Debuggen>Windows>Disassembly aus, oder drücken Sie ALT+8.
  1. Öffnen Sie den Ordner mit Ihren Partneranwendungen. Visual Studio Code erkennt die Arbeitsbereichsdatei und fragt Sie, ob Sie den Arbeitsbereich öffnen möchten. Wählen Sie Arbeitsbereich öffnen aus, um die Echtzeitanwendung und die allgemeine Anwendung gleichzeitig zu öffnen.

  2. Klicken Sie mit der rechten Maustaste auf eine der beiden CMakeLists.txt Dateien, und wählen Sie Alle Projekte erstellen aus.

  3. Klicken Sie auf der Visual Studio Code-Aktivitätsleiste auf das Symbol Ausführen.

  4. Wählen Sie im Pulldownmenü, das oben im Fenster auf der linken Seite des Bildschirms angezeigt wird, Die Option Azure Sphere-Apps (gdb)(Arbeitsbereich) starten aus.

  5. Drücken Sie F5, um das Projekt zu erstellen und zu debuggen. Wenn das Projekt noch nicht erstellt wurde oder dateien geändert wurden und eine Neuerstellung erforderlich ist, erstellt Visual Studio Code das Projekt, bevor das Debuggen gestartet wird.

  6. Warten Sie einige Sekunden, bis Visual Studio Code die Anwendungen erstellt, die Imagepakete erstellt, auf dem Board bereitgestellt und im Debugmodus gestartet wird. Auf dem Weg werden status Updates im Bereich Ausgabe angezeigt.

    Zunächst bestimmt CMake, ob die Anwendungen erstellt werden müssen. Wenn ja, verschiebt sich der Fokus auf das Ausgabefenster, in dem die Ausgabe von CMake/Build angezeigt wird.

    Als Nächstes wird im Ausgabebereich die Ausgabe von azsphere angezeigt, während das Imagepaket auf dem Gerät bereitgestellt wird. Schließlich erhält die Debugkonsole den Fokus und zeigt die gdb-Ausgabe an.

Verwenden Sie den Visual Studio Code-Debugger , um Haltepunkte festzulegen, die Anwendung anzuhalten, zu überspringen, neu zu starten oder zu beenden.

Während sie an einem Haltepunkt in Ihrem C-Quellcode beendet wurde, können Sie eine Disassemblierungsansicht öffnen, die die aktuelle Adresse, hexadezimierte Rohdaten, den Assembler mnemonisch für den aktuellen Befehl und Informationen wie die beteiligten Register oder den ausgeführten Quellcodebefehl anzeigt.

So öffnen Sie die Disassemblierungsansicht:

  1. Stellen Sie sicher, dass die C-Code-Quelldatei, die den Haltepunkt enthält, in einem Visual Studio Code-Editor geöffnet ist.
  2. Klicken Sie entweder mit der rechten Maustaste in das Editorfenster, und wählen Sie Disassemblansicht öffnen aus, oder wählen Sie Ansicht>Befehlspalette>Disassemblansicht öffnen aus.
  1. Beenden Sie die Echtzeitanwendung, wenn sie ausgeführt wird.

    azsphere device app stop --component-id <component id>
    
  2. Starten Sie die Echtzeitanwendung mit Debuggen neu.

    azsphere device app start --component-id <component id>
    

    Dieser Befehl gibt den Kern zurück, auf dem die Anwendung ausgeführt wird.

      <component id>
      App state   : running
      Core        : Real time 0
    
  3. Navigieren Sie zum Ordner Openocd für die sysroot-Datei, mit der die Anwendung erstellt wurde. Die sysroots werden im Installationsordner des Azure Sphere SDK installiert. Unter Windows wird der Ordner beispielsweise standardmäßig unter C:\Program Files (x86)\Microsoft Azure Sphere SDK\Sysroots\*sysroot*\tools\openocd und unter Linux unter /opt/azurespheresdk/Sysroots/*sysroot*/tools/sysroots/x86_64-pokysdk-linuxinstalliert.

  4. Führen Sie openocd wie im folgenden Beispiel gezeigt aus. Im Beispiel wird davon ausgegangen, dass die App auf Kern 0 ausgeführt wird. Wenn die App auf Kern 1 ausgeführt wird, ersetzen Sie "targets io0" durch "targets io1".

    openocd -f mt3620-rdb-ftdi.cfg -f mt3620-io0.cfg -c "gdb_memory_map disable" -c "gdb_breakpoint_override hard" -c init -c "targets io0" -c halt -c "targets"
    
  5. Öffnen Sie eine Befehlszeilenschnittstelle mithilfe von PowerShell, der Windows-Eingabeaufforderung oder der Linux-Befehlsshell.

  6. Navigieren Sie zu dem Ordner, der die .out-Datei der Echtzeitanwendung enthält, und starten Sie arm-none-eabi-gdb, die Teil der GNU Arm Embedded Toolchain ist:

    Windows-Eingabeaufforderung

    "C:\Program Files (x86)\GNU Arm Embedded Toolchain\9 2020-q2-update\bin\arm-none-eabi-gdb" IntercoreComms_RTApp_MT3620_BareMetal.out
    

    Windows PowerShell

    & "C:\Program Files (x86)\GNU Arm Embedded Toolchain\9 2020-q2-update\bin\arm-none-eabi-gdb" IntercoreComms_RTApp_MT3620_BareMetal.out
    
  7. Der OpenOCD-Server stellt eine GDB-Serverschnittstelle unter :4444 bereit. Legen Sie das Ziel für das Debuggen fest.

    target remote :4444

  8. Sie können jetzt gdb-Befehle ausführen. Fügen Sie einen Haltepunkt an der Funktion HandleSendTimerDeferred hinzu:

    break HandleSendTimerDeferred

  9. Der verbundene Terminalemulator sollte die Ausgabe der Echtzeitanwendung anzeigen.

  10. Öffnen Sie eine neue Azure Sphere-Eingabeaufforderung (Windows) oder ein Terminalfenster (Linux).

  11. Navigieren Sie zu dem Ordner, der die imagepackage-Datei der allgemeinen Anwendung enthält.

  12. Wenn die Anwendung ausgeführt wird, beenden Sie sie, und starten Sie sie dann mit dem Debuggen neu:

    azsphere device app stop --component-id <ComponentId>
    
    azsphere device app start --debug-mode --component-id <ComponentId>
    
  13. Öffnen Sie einen Terminalemulator , und stellen Sie eine Telnet- oder TCP-Verbindung mit 192.168.35.2 an Port 2342 her, um die Ausgabe der allgemeinen App anzuzeigen.

  14. Starten Sie gdb mit dem folgenden Befehl:

    Windows-Eingabeaufforderung

    "C:\Program Files (x86)\Microsoft Azure Sphere SDK\Sysroots\*sysroot*\tools\gcc\arm-poky-linux-musleabi-gdb.exe" IntercoreComms_HighLevelApp.out
    

    Windows PowerShell

    & "C:\Program Files (x86)\Microsoft Azure Sphere SDK\Sysroots\*sysroot*\tools\gcc\arm-poky-linux-musleabi-gdb.exe" IntercoreComms_HighLevelApp.out
    

    Hinweis

    Das Azure Sphere SDK wird mit mehreren Sysroots ausgeliefert, sodass Anwendungen verschiedene API-Sätze als Ziel verwenden können, wie unter Anwendungslaufzeitversion, Sysroots und Beta-APIs beschrieben. Die Sysroots werden im Installationsordner des Azure Sphere SDK unter Sysroots installiert.

  15. Legen Sie das Remotedebuggingziel auf Port 2345 auf die IP-Adresse 192.168.35.2 fest:

    target remote 192.168.35.2:2345
    
  16. Fügen Sie einen Haltepunkt an der Funktion SendMessageToRTApp hinzu:

    break SendMessageToRTApp
    
  17. Geben Sie c ein, um fortzufahren, beobachten Sie die Ausgabe in Ihrem Telnet/TCP-Terminal, und wechseln Sie dann zur Eingabeaufforderung oder zum Terminalfenster, das Ihre Echtzeit-Anwendungsdebugsitzung enthält.

  18. Geben Sie ein c , um fortzufahren und die Ausgabe in Der verbundenen seriellen Sitzung zu beobachten.

Sie können zwischen Debugsitzungen hin- und herarbeiten und zwischen der echtzeitfähigen Anwendung und der allgemeinen Anwendung wechseln. In den beiden Ausgabefenstern sollte eine Ausgabe ähnlich der folgenden angezeigt werden:

Starting debugger....
                     Process /mnt/apps/25025d2c-66da-4448-bae1-ac26fcdd3627/bin/app created; pid = 40
                     Listening on port 2345
                                           Remote debugging from host 192.168.35.1, port 56522
              High-level intercore comms application
                                                    Sends data to, and receives data from a real-time capable application.
                                          Sending: hl-app-to-rt-app-00
                                                                      Sending: hl-app-to-rt-app-01
IntercoreComms_RTApp_MT3620_BareMetal
App built on: Nov 17 2020, 09:25:19
Sender: 25025d2c-66da-4448-bae1-ac26fcdd3627
Message size: 19 bytes:
Hex: 68:6c:2d:61:70:70:2d:74:6f:2d:72:74:2d:61:70:70:2d:30:30
Text: hl-app-to-rt-app-00

Um jede Debugsitzung zu beenden, geben Sie q an der gdb-Eingabeaufforderung ein.