Eseguire il debug di un'applicazione che supporta il debug in tempo reale

  • Articolo

Le applicazioni RTApp vengono sottoposte a debug con OpenOCD, installato con Azure Sphere SDK, e la versione di GDB installata come parte del Toolchain ARM SCREENSHOT Embedded.

Eseguire il debug di RTApp con Visual Studio

  1. Verifica che il dispositivo sia connesso al PC tramite USB. Nel menu imposta elemento di avvio , seleziona App Azure Sphere (RT Core), dove App Azure Sphere è il nome dell'applicazione che supporta il tempo reale corrente o premi F5.

    Pulsante Debugger GDB remoto

  2. Se viene richiesto di creare il progetto, selezionare Sì. Visual Studio compila l'applicazione che supporta in tempo reale, crea un pacchetto di immagini, lo carica in sideload sulla bacheca e lo avvia in modalità debug. Il sideload significa che l'applicazione viene fornita direttamente dal PC tramite una connessione cablata, invece che tramite cloud.

    Notal'ID immagine del pacchetto di immagininell'output Mostra outputdi visualizzazione>> da: Output build Quando sei pronto per creare una distribuzione, dovrai conoscere il percorso del pacchetto di immagini.

  3. Per impostazione predefinita, la finestra Output mostra l'output da Output dispositivo. Per visualizzare i messaggi del debugger, selezionare Debug dal menu a discesa Mostra output da : . Puoi anche esaminare lo smontaggio del programma, i registri o la memoria tramite il menu Debug>Di Windows .

Visual Studio configura le connessioni tra il server GDB e OpenOCD in modo da poter usare l'interfaccia di debug standard di Visual Studio (F5, F6, F9 per i punti di interruzione e così via) su un'app RTApp, allo stesso modo di un'app di alto livello.

Durante l'interruzione in corrispondenza di un punto di interruzione nel codice sorgente C, è possibile aprire una finestra Disassembly che mostra l'indirizzo corrente, il mnemonic assembler per il comando corrente e informazioni come i registri coinvolti o il comando codice sorgente in esecuzione.

Per aprire la finestra Disassembly :

  1. Assicurarsi che il file di origine codice C contenente il punto di interruzione sia aperto in Visual Studio.
  2. Seleziona Debug>Windows>Disassembly o premi ALT+8.

Eseguire il debug di RTApp con Visual Studio Code

Visual Studio Code viene eseguito il debug premendo F5 o eseguendo il comando di debug dalla visualizzazione debug sulla barra sinistra. Negli esempi, il file .vscode/launch.json esiste già, quindi il debug verrà avviato immediatamente. In una nuova app, il debug richiederà innanzitutto se si tratta di una HLApp o RTApp, e creare un .vscode/launch.json dalla risposta. Il debug verrà quindi abilitato.

Mentre ti fermi a un punto di interruzione nel codice sorgente C, puoi aprire una visualizzazione Disassembly che mostra l'indirizzo corrente, i dati esadecimali non elaborati, il mnemonic assembler per il comando corrente e informazioni come i registri coinvolti o il comando codice sorgente in esecuzione.

Per aprire la visualizzazione Disassembly:

  1. Assicurarsi che il file sorgente codice C contenente il punto di interruzione sia aperto in un editor di Visual Studio Code.
  2. Fare clic con il pulsante destro del mouse nella finestra dell'editor e scegliere Apri visualizzazione disassembly o Visualizza>tavolozza dei comandi>Apri visualizzazione disassembly.

Eseguire il debug dell'RTApp con cli

  1. Avviare l'applicazione per il debug:

    az sphere device app start --component-id <component id>

    Questo comando restituisce il core su cui è in esecuzione l'applicazione.

  2. Passa alla cartella Openocd per la sysroot con cui è stata creata l'applicazione. In questa Guida introduttiva, sysroot è 5+Beta2004. Le sysroot vengono installate nella cartella di installazione di Azure Sphere SDK. Ad esempio, in Windows la cartella è installata per impostazione predefinita su C:\Program Files (x86)\Microsoft Azure Sphere SDK\Sysroots\5+Beta2004\tools\openocd e su Linux, in /opt/azurespheresdk/Sysroots/5+Beta2004/tools/sysroots/x86_64-pokysdk-linux/usr/bin/openocd.

  3. Esegui openocd come illustrato nell'esempio seguente. L'esempio presuppone che l'app sia in esecuzione sul core 0. Se l'app è in esecuzione sul core 1, sostituisci "targets io0" con "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"

  4. Aprire un'interfaccia della riga di comando usando PowerShell, il prompt dei comandi di Windows o la shell dei comandi di Linux.

  5. Passare alla cartella che contiene il file .out dell'applicazione e start arm-none-eabi-gdb, che fa parte del toolchain ARM DIRECTORY Embedded:

    Prompt dei comandi di Windows

    "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

  6. Il server OpenOCD fornisce un'interfaccia server GDB su :4444. Impostare la destinazione per il debug.

    target remote :4444

  7. Esegui i comandi gdb scelti.

Sviluppare con le app partner

Quando si carica un'applicazione nel dispositivo Azure Sphere, gli strumenti di distribuzione di Azure Sphere eliminano per impostazione predefinita tutte le applicazioni esistenti. Per evitare che ciò si verifichi quando si sviluppano applicazioni che comunicano tra loro, è necessario contrassegnare le applicazioni come partner. Quando si distribuisce una delle applicazioni, i relativi partner non verranno eliminati. Per informazioni dettagliate, vedere Contrassegnare le applicazioni come partner .

Risoluzione dei problemi relativi

Se si verificano problemi, vedi Risoluzione dei problemi relativi alle applicazioni in tempo reale.