Esercitazione: Compilare ed eseguire il debug di applicazioni partner

  • Articolo

In questa esercitazione viene illustrato come creare ed eseguire il debug di un progetto di esempio che include sia un'applicazione di alto livello che un'applicazione 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 che supportato in tempo reale.

In questa esercitazione imparerai come:

  • Installare il porta toolchain ARM DIVA
  • Configurare l'hardware per la visualizzazione dell'output
  • Abilitare lo sviluppo e il debug
  • Clonare il repository di esempio 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 che segue l'hardware per la progettazione della scheda di riferimento (RDB, Reference Board Design) MT3620, ad esempio MT3620 Dev Kit di Seeed Studios. Se usi hardware Azure Sphere diverso, consulta la documentazione del produttore per scoprire se l'oggetto 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 oggetto UART diverso.

Prerequisiti

Installare il toolchain ARM Embedded di HUX

  • Visual Studio 2022: se si usa Visual Studio 2022, installare IL TOOLCHAIN (arm-none-eabi) DIED (ARM Embedded Toolchain) 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 usi Visual Studio 2019, vai a Configurare l'hardware per la visualizzazione dell'output. Tuttavia, se è stato installato manualmente il toolchainCELL ARM Embedded, Visual Studio userà la versione installata.

Per installare il toolchain nel sito Web di sviluppo Arm, trova il TOOLCHAIN (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 il toolchain e dovrebbe trovare la versione installata. Se si verificano problemi di compilazione relativi alla toolchain, controllare Preferenze>Impostazioni>Estensioni>AzureSfera per assicurarsi che "Azure Sphere: Arm Cortana Path" identifichi la directory di installazione toolchain DITE ARM Embedded.

Configurare l'hardware per la visualizzazione dell'output

Attualmente, ogni core in tempo reale supporta un oggetto UART solo TX. RTApps può usare questo oggetto UART per inviare l'output del log dal dispositivo. Durante lo sviluppo e il debug delle applicazioni, in genere è necessario un modo per leggere e visualizzare l'output. L'esempio HelloWorld_RTApp_MT3620_BareMetal mostra come un'applicazione può scrivere nell'oggetto UART.

Usa un adattatore da USB a seriale, ad esempio FTDI Friend, per collegare l'UART nel core in tempo reale a una porta USB del computer. È inoltre necessario un emulatore di terminale per stabilire una connessione seriale con 115200-8-N-1 impostazioni del terminale (115200 bps, 8 bit, nessun bit di parità, un bit di interruzione) per visualizzare l'output.

Per configurare l'hardware per la visualizzazione dell'output da un'RTApp, seguire questa procedura. Dovrai fare riferimento alla documentazione del produttore dell'hardware per determinare le posizioni dei pin. Se usi hardware che segue l'hardware per la progettazione della scheda di riferimento (RDB) MT3620, come MT3620 Dev Kit di Seeed Studios, l'analisi delle intestazioni dell'interfaccia RDB può aiutarti a determinare le posizioni dei pin.

  1. Collega GND sull'adattatore da USB a seriale a GND nel tuo dev kit. Sull'hardware MT3620 RDB, GND è Header 3, pin 2.

  2. Collega RX sull'adattatore da USB a seriale a IOM4-0 TX nel kit di sviluppo. Sull'hardware MT3620 RDB, IOM4-0 TX è Header 3, pin 6.

  3. Collega l'adattatore da USB a seriale a una porta USB gratuita del computer di sviluppo e determina a quale porta è collegato il dispositivo seriale.

    • In Windows, avvia Gestione dispositivi, seleziona Visualizza>dispositivi per contenitore e cerca "USB UART". Ad esempio, FT232R USB UART indica l'adattatore FTDI Friend.

    • Su Linux digita il comando seguente:

      dmesg | grep ttyUSB

      La porta deve essere denominata ttyUSBn, dove n indica il numero di porta. Se il dmesg comando elenca più porte USB, quella collegata all'ultima di solito segnalata come collegata. Ad esempio, nei seguenti casi 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. Avvia un programma di emulatore terminale e apri un terminale 115200-8-N-1 sulla porta COM utilizzata dall'adattatore. Consulta la documentazione dell'emulatore del terminale per scoprire come specificare la porta e la velocità.

Abilitare lo sviluppo e il debug

Prima di poter creare un'applicazione di esempio nel 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 di applicazioni in fase di sviluppo da un PC e non consentono 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.

Per eseguire il debug sui core in tempo reale, utilizza il comando di abilitazione-sviluppo del dispositivo az sphere . Questo comando configura il dispositivo in modo da accettare le applicazioni da un PC per il debug e assegna il dispositivo al gruppo di dispositivi di 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 che gli aggiornamenti delle applicazioni cloud non sovrascriva l'applicazione in fase di sviluppo.

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. Se non l'hai già fatto, accedi ad Azure Sphere:

    az 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 driver USB per il debugger.

  3. Immettere il comando seguente:

    az sphere device enable-development --enable-rt-core-debugging  --catalog <CatalogName>  --resource-group <ResourceGroupName>

  4. Chiudere la finestra al termine del comando perché il privilegio di amministratore non è più necessario. Come procedura consigliata, è consigliabile usare sempre il privilegio più basso che può eseguire un'attività.

Se il comando di abilitazione-sviluppo del dispositivo az sphere non riesce, vedi Risolvere i problemi di Azure Sphere per assistenza.

Scaricare l'applicazione di esempio

Puoi scaricare le applicazioni InterCore Communications nel modo seguente:

  1. Punta il browser al browser Microsoft Samples.
  2. Digita "Azure Sphere" nella casella Search.
  3. Seleziona Azure Sphere - Inter-core Communications dai risultati della ricerca.
  4. Seleziona Scarica ZIP.
  5. Aprire il file scaricato ed estrarre il file in una directory locale.

Creare ed eseguire le applicazioni partner

  1. Avviare Visual Studio. Seleziona Apri una cartella locale e passa alla cartella in cui hai estratto le applicazioni IntercoreComms.

    Importante

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

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

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

  4. In Visual Studio, Visualizza>output>show output da: CMake output should show the messages CMake generation started and CMake generation finished.

  5. Seleziona Compila compila>tutto. Se il menu non è presente, aprire Esplora soluzioni, fare clic con il pulsante destro del mouse sul file CMakeLists.txt e scegliere Genera. Nella finestra Output viene visualizzata la posizione di output delle applicazioni IntercoreComms_HL & IntercoreComms RT.

  6. Seleziona Seleziona Startup Item>IntercoreComms (All cores).

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

  8. Nella finestra Output, seleziona Output dispositivo dal menu Seleziona output da. Nella finestra Output dovrebbe essere visualizzato l'output dell'applicazione di alto livello:

    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 che supporta il 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 estratte le applicazioni IntercoreComms. Visual Studio Code rileva il file intercore.code-workspace e chiede se vuoi aprire l'area di lavoro. Seleziona Apri area di lavoro per aprire contemporaneamente l'applicazione in tempo reale e l'applicazione di alto livello.

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

  3. Premere F5 per avviare il debugger. Se il progetto non è stato creato in precedenza o se i file sono stati modificati e la ricostruzione è obbligatoria, Visual Studio Code crea il progetto prima dell'inizio del debug.

  4. La finestra di output di Azure Sphere dovrebbe mostrare "Immagine di distribuzione..." seguito dai percorsi dell'SDK e del compilatore.

  5. Nella finestra di output dovrebbe essere visualizzato l'output dell'applicazione di alto livello:

    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 che supporta il 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. Usa 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 relativi

L'applicazione potrebbe iniziare l'esecuzione prima di OpenOCD effettua una connessione. Di conseguenza, i punti di interruzione impostati all'inizio del codice potrebbero non essere presenti. Una soluzione alternativa consiste nel posticipare l'avvio dell'app finché OpenOCD non si connette.

  1. Inserire il codice seguente all'inizio del punto di ingresso dell'applicazione RTCoreMain. In questo modo l'applicazione verrà immessa e rimarrà in un while ciclo fino a quando la variabile f non viene impostata su true.

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

  2. Premi F5 per avviare l'app con il debug e quindi interrompo l'esecuzione.

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

  4. Scorrere il codice come al solito.

Durante la compilazione con l'cli, è necessario prima di tutto creare e distribuire l'applicazione che supporta in tempo reale, quindi creare e distribuire l'applicazione di alto livello.

Creare e distribuire l'applicazione che supporta il supporto in tempo reale

  1. Passa alla cartella in cui sono estratte le applicazioni IntercoreComms e quindi seleziona la cartella IntercoreComms/IntercoreComms_RTApp_MT3620_BareMetal.

  2. Apri il file app_manifest.json e verifica che l'ID componente dell'app di livello elevato 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 di Linux. Passare alla directory della build 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 preimpostato per la configurazione della build, come definito in CMakePresets.json.

    • --build <cmake-path>

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

    • <source-path>

      Percorso della directory che contiene i file di origine per l'applicazione di esempio. Nell'esempio, il repository di campioni Azure Sphere è stato scaricato in una directory denominata AzSfera.

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

    Gli esempi seguenti mostrano 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 della build del progetto, al prompt dei comandi, esegui Ninja per creare l'applicazione e creare il file del pacchetto di immagini.

    ninja -C out/ARM-Debug

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

    Puoi anche 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 su un esempio di Azure Sphere, il comando di compilazione sarà cmake --build out/ARM-Debug.

    Durante la risoluzione dei problemi, soprattutto dopo aver apportato modifiche ai comandi di CMake, eliminare l'intera build e riprovare.

  6. Eliminare le applicazioni già distribuite nel dispositivo:

    az sphere device sideload delete

  7. Dalla directory della build di progetto, al prompt dei comandi, carica il pacchetto di immagini creato da Ninja:

    az sphere device sideload deploy --image-package <path-to-imagepackage>

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

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

    az sphere image-package show --image-package <path-to-imagepackage>

    Il comando restituisce tutti i metadati per il pacchetto di immagini. L'ID componente per l'applicazione viene visualizzato nella sezione Identity relativa al tipo di immagine dell'applicazione. Per esempio:

    ...
  "Identity": {
    "ComponentId": "<component-id>",
    "ImageId": "<image-id>",
    "ImageType": "Application"
  },
...

Creare e distribuire l'applicazione di alto livello

  1. Passa alla cartella in cui sono estratte le applicazioni IntercoreComms e quindi seleziona la cartella IntercoreComms/IntercoreComms_HighLevelApp.

  2. Aprire il file app_manifest.json e verificare che l'ID componente dell'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 di Linux. Passare alla directory della build 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 preimpostato per la configurazione della build, come definito in CMakePresets.json.

    • --build <cmake-path>

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

    • <source-path>

      Percorso della directory che contiene i file di origine per l'applicazione di esempio. Nell'esempio, il repository di campioni Azure Sphere è stato scaricato in una directory denominata AzSfera.

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

    Gli esempi seguenti mostrano 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 della build del progetto, al prompt dei comandi, esegui Ninja per creare l'applicazione e creare il file del pacchetto di immagini.

    ninja -C out/ARM-Debug

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

    Puoi anche 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 su un esempio di Azure Sphere, il comando di compilazione sarà cmake --build out/ARM-Debug.

    Durante la risoluzione dei problemi, soprattutto dopo aver apportato modifiche ai comandi di CMake, eliminare l'intera build e riprovare.

  6. Dalla directory della build di progetto, al prompt dei comandi, carica il pacchetto di immagini creato da Ninja:

    az sphere device sideload deploy --image-package <package-name>

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

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

    az sphere image-package show --image-package <path-to-imagepackage>

    Il comando restituisce tutti i metadati per il pacchetto di immagini. L'ID componente per l'applicazione viene visualizzato nella sezione Identity relativa al tipo di immagine dell'applicazione. Per esempio:

    ...
  "Identity": {
    "ComponentId": "<component-id>",
    "ImageId": "<image-id>",
    "ImageType": "Application"
  },
...

Eseguire le applicazioni partner con il debug abilitato

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

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

  2. Riavviare l'applicazione per il debug.

    az sphere device app start -- --debug-mode true --component-id <component id>

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

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

  3. Passa alla cartella Openocd per la sysroot con cui è stata creata l'applicazione. 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\*sysroot*\tools\openocd e su Linux, in /opt/azurespheresdk/Sysroots/*sysroot*/tools/sysroots/x86_64-pokysdk-linux.

  4. 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"

  5. Apri un nuovo prompt dei comandi di Azure Sphere (cli classico di Windows Azure Sphere), un prompt dei comandi standard o una finestra del terminale (Linux) di PowerShell (Windows Azure CLI).

  6. Passare alla cartella che contiene il file .out dell'applicazione in tempo reale che supporta e avviare arm-none-eabi-gdb, che fa parte del toolchain CPU Arm 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

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

    target remote :4444

  8. È ora possibile eseguire i comandi gdb nell'applicazione che supporta il supporto in tempo reale. Aggiungere un punto di interruzione in corrispondenza della funzione HandleSendTimerDeferred:

    break HandleSendTimerDeferred

  9. L'emulatore del terminale connesso deve visualizzare l'output dall'applicazione che supporta il tempo reale.

  10. Apri un nuovo prompt dei comandi di Azure Sphere (cli classico di Windows Azure Sphere), un prompt dei comandi standard o una finestra del terminale (Linux) di PowerShell (Windows Azure CLI).

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

  12. Interrompere l'applicazione di livello elevato se è in esecuzione.

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

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

    az sphere device app start --debug-mode true --component-id <component id> --debug-mode

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

  15. Avvia 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 essere destinate a set DI API diversi, come descritto nella versione di Runtime dell'applicazione, sysroots e API Beta. I sysroot vengono 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. Digita c per continuare, osserva l'output nel terminale Telnet/TCP, quindi passa al prompt dei comandi o alla finestra terminale contenente la sessione di debug dell'applicazione in tempo reale.

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

È possibile spostarsi tra le sessioni di debug, passando tra l'applicazione che supporta il tempo reale e l'applicazione di alto livello. Nelle due finestre di output dovrebbe essere visualizzato un output simile al seguente:

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, digita q al prompt di gdb.

Passaggi successivi