Condividi tramite

Esercitazione: Compilare ed eseguire il debug di applicazioni partner

  • Articolo

Importante

Questa è la documentazione di Azure Sphere (legacy). Azure Sphere (legacy) viene ritirato il 27 settembre 2027 e gli utenti devono eseguire la migrazione ad Azure Sphere (integrato) entro questo periodo. Usare il selettore di versione posizionato sopra il sommario per visualizzare la documentazione di Azure Sphere (integrata).

Questa esercitazione illustra come compilare ed eseguire il debug di un progetto di esempio che include sia un'applicazione di alto livello che un'applicazione con funzionalità in tempo reale, in cui le due app comunicano tra il core A7 di alto livello e il core M4 in tempo reale. Vedere Panoramica delle applicazioni Azure Sphere per informazioni di base sulle applicazioni di alto livello e sulle applicazioni con funzionalità in tempo reale.

In questa esercitazione apprenderai a:

  • Installare la toolchain GNU Arm
  • Configurare l'hardware per visualizzare l'output
  • Abilitare lo sviluppo e il debug
  • Clonare il repository di esempio di Azure Sphere
  • Avviare un emulatore di terminale per visualizzare l'output
  • Compilare, eseguire ed eseguire il debug di una coppia di applicazioni partner

Importante

Queste istruzioni presuppongono l'uso di hardware conforme alla progettazione della scheda di riferimento (RDB) MT3620, ad esempio MT3620 Dev Kit di Seeed Studios. Se si usa un hardware di Azure Sphere diverso, consultare la documentazione del produttore per scoprire se UART è esposto e come accedervi. Potrebbe essere necessario configurare l'hardware per visualizzare l'output in modo diverso e aggiornare il codice di esempio e il campo "Uarts" del file app_manifest.json per usare un dispositivo UART diverso.

Prerequisiti

Installare GNU Arm Embedded Toolchain

  • Visual Studio 2022: se si usa Visual Studio 2022, installare gnu Arm Embedded Toolchain (arm-none-eabi) dal sito Web per sviluppatori Arm.
  • Visual Studio 2019: la toolchain viene installata automaticamente con l'estensione Azure Sphere per Visual Studio in Visual Studio 2019. Se si usa Visual Studio 2019, passare a Configurare l'hardware per visualizzare l'output. Tuttavia, se è stata installata manualmente la toolchain GNU Arm Embedded, Visual Studio userà la versione installata.

Per installare la toolchain, nel sito Web per sviluppatori arm trovare la toolchain GNU Arm Embedded (arm-none-eabi) che include il compilatore per il processore ARM Cortex-M4. Seguire le istruzioni per scaricare e installare il compilatore per la piattaforma del sistema operativo.

Per impostazione predefinita, Visual Studio Code cerca la toolchain e trova la versione installata. Se si verificano problemi di compilazione correlati alla toolchain, selezionare Preferences Settings>>Extensions>AzureSphere per assicurarsi che "Azure Sphere: Arm Gnu Path" identifichi la directory di installazione di GNU Arm Embedded Toolchain.

Configurare l'hardware per visualizzare l'output

Tutti i core per operazioni in tempo reale supportano attualmente un dispositivo UART solo TX. Le RTApp usano questo UART per inviare l'output del log dal dispositivo. Durante lo sviluppo e il debug di applicazioni, in genere è necessario un modo per leggere e visualizzare l'output. L'esempio HelloWorld_RTApp_MT3620_BareMetal illustra come un'applicazione può scrivere in UART.

Usare un adattatore USB-seriale, ad esempio FTDI Friend, per connettere il dispositivo UART nel core per operazioni in tempo reale alla porta USB del computer. È necessario anche un emulatore di terminale per stabilire una connessione seriale con le impostazioni del terminale 115200-8-N-1 (115200 bps, 8 bit, senza bit di parità, un bit di arresto) per visualizzare l'output.

Per configurare l'hardware per visualizzare l'output da un'app in tempo reale, seguire questa procedura. Per determinare le posizioni dei pin, è necessario fare riferimento alla documentazione del produttore dell'hardware. Se si usa un hardware che segue l'hardware di progettazione della scheda di riferimento (RDB, Reference Board Design) MT3620, ad esempio il kit di sviluppo MT3620 di Seeed Studios, vedere le intestazioni dell'interfaccia RDB per determinare le posizioni dei pin.

  1. Collegare la messa a terra sull'adattatore da porta USB a seriale alla messa a terra sul kit di sviluppo. Nell'hardware RDB MT3620 la messa a terra corrisponde a intestazione 3, pin 2.

  2. Collegare il ricevitore dell'adattatore da porta USB a seriale al trasmettitore IOM4-0 del kit di sviluppo. Nell'hardware RDB MT3620 il trasmettitore IOM4-0 corrisponde a intestazione 3, pin 6.

  3. Connettere l'adattatore USB a seriale a una porta USB libera nel computer di sviluppo e determinare la porta a cui è connesso il dispositivo seriale.

    • In Windows avviare Gestione dispositivi selezionare Visualizza>dispositivi per contenitore e cercare "USB UART". Ad esempio, FT232R USB UART indica la scheda FTDI Friend.

    • In Linux digitare il comando seguente:

      dmesg | grep ttyUSB

      La porta dovrebbe essere denominata ttyUSBn, dove n indica il numero di porta. Se il dmesg comando elenca diverse porte USB, quella connessa all'ultima porta segnalata come collegata. Ad esempio, nell'esempio seguente si userà ttyUSB4:

    ~$ dmesg | grep ttyUSB
[  144.564350] usb 1-1.1.2: FTDI USB Serial Device converter now attached to ttyUSB0
[  144.564768] usb 1-1.1.2: FTDI USB Serial Device converter now attached to ttyUSB1
[  144.565118] usb 1-1.1.2: FTDI USB Serial Device converter now attached to ttyUSB2
[  144.565593] usb 1-1.1.2: FTDI USB Serial Device converter now attached to ttyUSB3
[  144.570429] usb 1-1.1.3: FTDI USB Serial Device converter now attached to ttyUSB4
[  254.171871] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1

  4. Avviare un programma emulatore di terminale e aprire un terminale 115200-8-N-1 sulla porta COM usata dall'adattatore. Per informazioni su come specificare la porta e la velocità, vedere la documentazione per l'emulatore del terminale.

Abilitare lo sviluppo e il debug

Prima di poter compilare un'applicazione di esempio sul dispositivo Azure Sphere o sviluppare nuove applicazioni, è necessario abilitare lo sviluppo e il debug. Per impostazione predefinita, i dispositivi Azure Sphere sono "bloccati", ovvero non consentono il caricamento da un PC di applicazioni in fase di sviluppo, oltre a non permettere il debug delle applicazioni. La preparazione del dispositivo per il debug rimuove questa restrizione e carica il software necessario per il debug e sblocca le funzionalità del dispositivo come descritto in Funzionalità del dispositivo e comunicazione.

Per eseguire il debug nei core in tempo reale, usare il comando azsphere device enable-development. Questo comando configura il dispositivo per accettare applicazioni da un PC per il debug e assegna il dispositivo al gruppo di dispositivi sviluppo, che non consente gli aggiornamenti delle applicazioni cloud. Durante lo sviluppo e il debug delle applicazioni, è consigliabile lasciare il dispositivo in questo gruppo in modo da evitare la sovrascrittura dell'applicazione in fase di sviluppo da parte degli aggiornamenti cloud.

In Windows è necessario aggiungere il --enable-rt-core-debugging parametro , che carica i server di debug e i driver necessari per ogni tipo di core nel dispositivo.

  1. Accedere ad Azure Sphere se non è già stato fatto:

    azsphere login

  2. Aprire un'interfaccia della riga di comando usando PowerShell o il prompt dei comandi di Windows con privilegi di amministratore. Il --enable-rt-core-debugging parametro richiede privilegi di amministratore perché installa i driver USB per il debugger.

  3. Immettere il comando seguente:

    azsphere device enable-development --enable-rt-core-debugging

  4. Chiudere la finestra dopo il completamento del comando perché il privilegio di amministratore non è più necessario. È consigliabile usare sempre il privilegio minimo necessario per eseguire un'attività.

Se il comando azsphere device enable-development non riesce, vedere Risolvere i problemi di Azure Sphere per assistenza.

Scaricare l'applicazione di esempio

È possibile scaricare le applicazioni InterCore Communications come segue:

  1. Puntare il browser a Microsoft Samples Browser.
  2. Digitare "Azure Sphere" nella casella Di ricerca.
  3. Selezionare Azure Sphere - Inter-core Communications nei risultati della ricerca.
  4. Selezionare Scarica ZIP.
  5. Aprire il file scaricato ed estrarre in una directory locale.

Compilare ed eseguire le applicazioni partner

  1. Avviare Visual Studio. Selezionare Apri una cartella locale e passare alla cartella in cui sono state estratte le applicazioni IntercoreComms.

    Importante

    Se si usa Visual Studio 2022 versione 17.1 o successiva ed è stato estratto l'esempio IntercoreComms prima della versione 22.02 di Azure Sphere, è necessario aggiungere un file CMakeWorkspaceSettings.json alla cartella di progetto di primo livello.

  2. Se non si usa un RDB MT3620, aggiornare i file di app_manifest.json sia per le applicazioni che per il file di definizione hardware e CMakeLists.txt per l'applicazione di alto livello in modo che corrisponda all'hardware.

  3. Se la generazione di CMake non viene avviata automaticamente, selezionare il file CMakeLists.txt.

  4. In Visual Studio visualizzare>l'output Mostra output>da: L'output di CMake dovrebbe visualizzare i messaggi CMake generation started e .CMake generation finished

  5. Selezionare Compila>tutto. Se il menu non è presente, aprire Esplora soluzioni, fare clic con il pulsante destro del mouse sul file CMakeLists.txt e scegliere Compila. Il percorso di output delle applicazioni IntercoreComms_HL e IntercoreComms RT viene visualizzato nella finestra Output .

  6. Selezionare Seleziona elemento di avvio IntercoreComms (Tutti i core).Select Startup Item>IntercoreComms (All cores).

  7. Selezionare Debug debug> o premere F5 per distribuire ed eseguire il debug delle applicazioni.

  8. Nella finestra Output selezionare output dal menu, selezionare Output dispositivo. La finestra Output dovrebbe visualizzare l'output generale dell'applicazione:

    Remote debugging from host 192.168.35.1, port 58817
High-level intercore comms application
Sends data to, and receives data from a real-time capable application.
Received 19 bytes: rt-app-to-hl-app-07
Sending: hl-app-to-rt-app-00
Sending: hl-app-to-rt-app-01

  9. L'emulatore del terminale connesso deve visualizzare l'output del programma con funzionalità in tempo reale:

    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
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:31
Text: hl-app-to-rt-app-01

  10. Usare il debugger per impostare i punti di interruzione, esaminare le variabili e provare altre attività di debug.

  1. In Visual Studio Code aprire la cartella in cui sono state estratte le applicazioni IntercoreComms. Visual Studio Code rileva il file intercore.code-workspace e chiede se si vuole aprire l'area di lavoro. Selezionare Apri area di lavoro per aprire sia l'applicazione in tempo reale che l'applicazione di alto livello contemporaneamente.

  2. Se non si usa un RDB MT3620, aggiornare i file di app_manifest.json sia per le applicazioni che per il file di definizione hardware e CMakeLists.txt per l'applicazione di alto livello in modo che corrisponda all'hardware.

  3. Premere F5 per avviare il debugger. Se il progetto non è già stato compilato oppure se i file sono stati cambiati ed è necessaria una ricompilazione, Visual Studio Code compilerà il progetto prima dell'avvio del debug.

  4. Nella finestra di output di Azure Sphere verrà visualizzato un messaggio che indica che è in corso la distribuzione dell'immagine, con i percorsi dell'SDK e del compilatore.

  5. La finestra di output dovrebbe mostrare l'output generale dell'applicazione:

    Remote debugging from host 192.168.35.1, port 58817
High-level intercore comms application
Sends data to, and receives data from a real-time capable application.
Received 19 bytes: rt-app-to-hl-app-07
Sending: hl-app-to-rt-app-00
Sending: hl-app-to-rt-app-01

  6. L'emulatore del terminale connesso deve visualizzare l'output del programma con funzionalità in tempo reale:

    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
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:31
Text: hl-app-to-rt-app-01

  7. Usare le funzionalità di debug di Visual Studio Code per impostare i punti di interruzione, esaminare le variabili e provare altre attività di debug.

Risoluzione dei problemi

È possibile che l'esecuzione dell'applicazione inizi prima che OpenOCD stabilisca una connessione. Di conseguenza, i punti di interruzione impostati precedentemente nel codice potrebbero essere ignorati. Per risolvere il problema, è possibile ritardare l'avvio dell'app fino a quando OpenOCD non stabilisce la connessione.

  1. Inserire il codice seguente all'inizio del punto di ingresso dell'applicazione RTCoreMain. In questo modo l'applicazione entrerà e rimarrà in un ciclo while finché la variabile f non sarà impostata su true.

    static _Noreturn void RTCoreMain(void)
{
  .
  .
  .
 volatile bool f = false;
 while (!f) {
    // empty.
 }
  .
  .
  .
}

  2. Premere F5 per avviare l'app con il debug e quindi interrompere l'esecuzione.

  3. Nel riquadro debug Variabili locali modificare il valore di f da zero a uno.

  4. Eseguire il codice come di consueto.

Quando si compila con l'interfaccia della riga di comando, si compila e si distribuisce l'applicazione con funzionalità in tempo reale, quindi si compila e distribuisce l'applicazione di alto livello.

Compilare e distribuire l'applicazione con funzionalità in tempo reale

  1. Passare alla cartella in cui sono state estratte le applicazioni IntercoreComms e quindi selezionare la cartella IntercoreComms/IntercoreComms_RTApp_MT3620_BareMetal.

  2. Aprire il file app_manifest.json e verificare che l'ID componente dell'app di alto livello sia visualizzato nella funzionalità AllowedApplicationConnections.

  3. Aprire un'interfaccia della riga di comando usando PowerShell, il prompt dei comandi di Windows o la shell dei comandi linux. Passare alla directory di compilazione del progetto.

  4. Dalla directory di compilazione del progetto, al prompt dei comandi eseguire CMake con i parametri seguenti:

    cmake --preset <preset-name> <source-path>

    • --preset <preset-name>

      Nome del set di impostazioni di configurazione della compilazione definito in CMakePresets.json.

    • --build <cmake-path>

      Directory binaria che contiene la cache CMake. Ad esempio, se si esegue CMake in un esempio di Azure Sphere, il comando di compilazione sarà cmake --build out/ARM-Debug.

    • <source-path>

      Percorso della directory contenente i file di origine per l'applicazione di esempio. Nell'esempio il repository di esempi di Azure Sphere è stato scaricato in una directory denominata AzSphere.

      I parametri di CMake sono separati da spazi. Il carattere di continuazione della riga (^ per la riga di comando di Windows, \ per la riga di comando linux o ' per PowerShell) può essere usato per la leggibilità, ma non è obbligatorio.

    Gli esempi seguenti illustrano i comandi CMake per IntercoreComms RTApp:

    Prompt dei comandi di Windows

     cmake ^
--preset "ARM-Debug" ^
 "C:\AzSphere\azure-sphere-samples\Samples\IntercoreComms\IntercoreComms_RTApp_MT3620_BareMetal"

    Windows PowerShell

     cmake `
--preset "ARM-Debug" `
 "C:\AzSphere\azure-sphere-samples\Samples\IntercoreComms\IntercoreComms_RTApp_MT3620_BareMetal"

  5. Dalla directory di compilazione del progetto eseguire Ninja al prompt dei comandi per compilare l'applicazione e creare il file del pacchetto immagine.

    ninja -C out/ARM-Debug

    Ninja inserisce l'applicazione risultante e i file imagepackage nella directory specificata.

    È anche possibile richiamare Ninja tramite CMake con il comando seguente:

    cmake --build out/<binary-dir>

    Impostare <binary-dir> sulla directory binaria che contiene la cache CMake. Ad esempio, se si esegue CMake in un esempio di Azure Sphere, il comando di compilazione sarà cmake --build out/ARM-Debug.

    Quando si esegue la risoluzione dei problemi, soprattutto dopo aver apportato modifiche ai comandi CMake, eliminare l'intera compilazione e riprovare.

  6. Eliminare tutte le applicazioni già distribuite nel dispositivo:

    azsphere device sideload delete

  7. Dalla directory di compilazione del progetto, al prompt dei comandi caricare il pacchetto immagine creato da Ninja:

    azsphere device sideload deploy --image-package <path-to-imagepackage>

    L'applicazione inizierà a essere eseguita subito dopo il caricamento.

  8. Identificare l'ID componente per l'immagine:

    azsphere image-package show --image-package <path-to-imagepackage>

    Il comando restituisce tutti i metadati per il pacchetto immagine. L'ID componente per l'applicazione si trova nella sezione Identità per il tipo di immagine dell'applicazione. Ad esempio:

    Image package metadata:
Section: Identity
Image Type:           Application
Component ID:         <component id>
Image ID:             <image id>

Compilare e distribuire l'applicazione di alto livello

  1. Passare alla cartella in cui sono state estratte le applicazioni IntercoreComms e quindi selezionare la cartella IntercoreComms/IntercoreComms_HighLevelApp.

  2. Aprire il file app_manifest.json e verificare che l'ID componente rtApp sia visualizzato nella funzionalità AllowedApplicationConnections.

  3. Aprire un'interfaccia della riga di comando usando PowerShell, il prompt dei comandi di Windows o la shell dei comandi linux. Passare alla directory di compilazione del progetto.

  4. Dalla directory di compilazione del progetto, al prompt dei comandi eseguire CMake con i parametri seguenti:

    cmake --preset <preset-name> <source-path>

    • --preset <preset-name>

      Nome del set di impostazioni di configurazione della compilazione definito in CMakePresets.json.

    • --build <cmake-path>

      Directory binaria che contiene la cache CMake. Ad esempio, se si esegue CMake in un esempio di Azure Sphere, il comando di compilazione sarà cmake --build out/ARM-Debug.

    • <source-path>

      Percorso della directory contenente i file di origine per l'applicazione di esempio. Nell'esempio il repository di esempi di Azure Sphere è stato scaricato in una directory denominata AzSphere.

      I parametri di CMake sono separati da spazi. Il carattere di continuazione della riga (^ per la riga di comando di Windows, \ per la riga di comando linux o ' per PowerShell) può essere usato per la leggibilità, ma non è obbligatorio.

    Gli esempi seguenti illustrano i comandi CMake per l'applicazione di alto livello IntercoreComms.

    Prompt dei comandi di Windows

     cmake ^
 --preset "ARM-Debug" ^
 "C:\AzSphere\azure-sphere-samples\Samples\IntercoreComms\IntercoreComms_HighLevelApp"

    Windows PowerShell

     cmake `
 --preset "ARM-Debug" `
 "C:\AzSphere\azure-sphere-samples\Samples\IntercoreComms\IntercoreComms_HighLevelApp"

  5. Dalla directory di compilazione del progetto eseguire Ninja al prompt dei comandi per compilare l'applicazione e creare il file del pacchetto immagine.

    ninja -C out/ARM-Debug

    Ninja inserisce l'applicazione risultante e i file imagepackage nella directory specificata.

    È anche possibile richiamare Ninja tramite CMake con il comando seguente:

    cmake --build out/<binary-dir>

    Impostare <binary-dir> sulla directory binaria che contiene la cache CMake. Ad esempio, se si esegue CMake in un esempio di Azure Sphere, il comando di compilazione sarà cmake --build out/ARM-Debug.

    Quando si esegue la risoluzione dei problemi, soprattutto dopo aver apportato modifiche ai comandi CMake, eliminare l'intera compilazione e riprovare.

  6. Dalla directory di compilazione del progetto, al prompt dei comandi caricare il pacchetto immagine creato da Ninja:

    azsphere device sideload deploy --image-package <package-name>

    L'applicazione inizierà a essere eseguita subito dopo il caricamento.

  7. Identificare l'ID componente per l'immagine:

    azsphere image-package show --image-package <path-to-imagepackage>

    Il comando restituisce tutti i metadati per il pacchetto immagine. L'ID componente per l'applicazione si trova nella sezione Identità per il tipo di immagine dell'applicazione. Ad esempio:

    Image package metadata:
  Section: Identity
    Image Type:           Application
    Component ID:         <component id>
    Image ID:             <image id>

Eseguire le applicazioni partner con il debug abilitato

  1. Arrestare l'applicazione in tempo reale se è in esecuzione.

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

  2. Riavviare l'applicazione per il debug.

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

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

      <component id>
  App state: running
  Core        : Real-time 0

  3. Passare alla cartella Openocd per il sysroot in cui è stata creata l'applicazione. I sysroot sono installati nella cartella di installazione di Azure Sphere SDK. Ad esempio, in Windows la cartella viene installata per impostazione predefinita in C:\Program Files (x86)\Microsoft Azure Sphere SDK\Sysroots\*sysroot*\tools\openocd e in Linux in /opt/azurespheresdk/Sysroots/*sysroot*/tools/sysroots/x86_64-pokysdk-linux.

  4. Eseguire openocd come illustrato nell'esempio seguente. L'esempio presuppone che l'app sia in esecuzione nella core 0. Se l'app è in esecuzione nel core 1, sostituire "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"

  5. Aprire un nuovo prompt dei comandi di Azure Sphere (interfaccia della riga di comando classica di Windows Azure Sphere), un prompt dei comandi standard o PowerShell (interfaccia della riga di comando di Windows Azure Sphere) o una finestra del terminale (Linux).

  6. Passare alla cartella che contiene il file con estensione out dell'applicazione in tempo reale e avviare arm-none-eabi-gdb, che fa parte di GNU Arm Embedded Toolchain:

    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

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

    target remote :4444

  8. È ora possibile eseguire comandi gdb nell'applicazione con funzionalità in tempo reale. Aggiungere un punto di interruzione alla funzione HandleSendTimerDeferred:

    break HandleSendTimerDeferred

  9. L'emulatore del terminale connesso deve visualizzare l'output dell'applicazione con supporto in tempo reale.

  10. Aprire un nuovo prompt dei comandi di Azure Sphere (interfaccia della riga di comando classica di Windows Azure Sphere), un prompt dei comandi standard o PowerShell (interfaccia della riga di comando di Windows Azure Sphere) o una finestra del terminale (Linux).

  11. Passare alla cartella che contiene il file imagepackage dell'applicazione di alto livello.

  12. Arrestare l'applicazione di alto livello se è in esecuzione.

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

  13. Riavviare l'applicazione di alto livello con il debug.

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

  14. Aprire un emulatore di terminale e stabilire una connessione Telnet o TCP alla porta 192.168.35.2 sulla porta 2342 per visualizzare l'output dell'app di alto livello.

  15. Avviare gdb con il comando seguente:

    Prompt dei comandi di Windows

    "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

    Nota

    Azure Sphere SDK viene fornito con più sysroot in modo che le applicazioni possano avere come destinazione set di API diversi, come descritto in Versione del runtime dell'applicazione, sysroot e API Beta. I sysroot sono installati nella cartella di installazione di Azure Sphere SDK in Sysroots.

  16. Impostare la destinazione di debug remoto sull'indirizzo IP 192.168.35.2 sulla porta 2345:

    target remote 192.168.35.2:2345

  17. Aggiungere un punto di interruzione alla funzione SendMessageToRTApp:

    break SendMessageToRTApp

  18. Digitare c per continuare, osservare l'output nel terminale Telnet/TCP, quindi passare al prompt dei comandi o alla finestra del terminale contenente la sessione di debug dell'applicazione in tempo reale.

  19. Digitare c per continuare e osservare l'output nella sessione seriale connessa.

È possibile lavorare avanti e indietro tra sessioni di debug, passando dall'applicazione con supporto in tempo reale all'applicazione di alto livello. L'output dovrebbe essere simile al seguente nelle due finestre di output:

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

Per terminare ogni sessione di debug, digitare q al prompt di gdb.

Passaggi successivi