チュートリアル: パートナーアプリケーションのビルドとデバッグ

[アーティクル]
08/09/2023

このチュートリアルでは、高レベルのアプリケーションとリアルタイム対応アプリケーションの両方を含むサンプルプロジェクトをビルドしてデバッグする方法について説明します。このアプリケーションは、高レベルの A7 コアとリアルタイム M4 コアの間で通信します。高度なアプリケーションとリアルタイム対応アプリケーションの基本的な情報については、「 Azure Sphere アプリケーションの概要」を参照してください。

このチュートリアルでは、次の方法について説明します。

GNU Arm ツールチェーンをインストールする
出力を表示するようにハードウェアを設定する
開発とデバッグを有効にする
Azure Sphere サンプルリポジトリを複製する
ターミナルエミュレーターを起動して出力を表示する
パートナーアプリケーションのペアをビルド、実行、デバッグする

大事な

これらの手順では、MT3620 リファレンスボード設計 (RDB) ハードウェア (Seeed Studios の MT3620 Dev Kit など) に従うハードウェアを使用していることを前提としています。別の Azure Sphere ハードウェアを使用している場合は、製造元のドキュメントを参照して、UART が公開されているかどうかを確認し、そのハードウェアにアクセスする方法を確認してください。出力を異なる方法で表示するようにハードウェアを設定し、app_manifest.json ファイルのサンプルコードと Uarts フィールドを更新して、別の UART を使用する必要がある場合があります。

前提条件

Windows または Linux 用の CMake と Ninja をインストールします。

Windows または Linux 用の Visual Studio Code をインストールします。
Windows または Linux 用の CMake と Ninja をインストールします。

Visual Studio と Azure Sphere 拡張機能をインストールします。

Windows または Linux 用の Azure Sphere SDK をインストールします。
カタログを選択し、デバイスを要求します。
ネットワークを構成し、デバイス OS を更新します。

GNU Arm Embedded Toolchain をインストールする

Visual Studio 2022: Visual Studio 2022 を使用している場合は、 Arm 開発者向け Web サイトから GNU Arm Embedded Toolchain (arm-none-eabi) をインストールします。
Visual Studio 2019: ツールチェーンは、Visual Studio 2019 の Visual Studio 用 Azure Sphere 拡張機能と共に自動的にインストールされます。 Visual Studio 2019 を使用している場合は、出力を表示するためのハードウェアのセットアップに進みます。ただし、GNU Arm Embedded Toolchain を手動でインストールした場合、Visual Studio はインストールしたバージョンを使用します。

Arm 開発者向け Web サイトにツールチェーンをインストールするには、ARM Cortex-M4 プロセッサのコンパイラを含む GNU Arm Embedded Toolchain (arm-none-eabi) を見つけます。こちらの手順に従って、OS プラットフォームのコンパイラをダウンロードしてインストールします。

既定では、Visual Studio Code はツールチェーンを検索し、インストールしたバージョンを見つける必要があります。ツールチェーンに関連するビルドの問題が発生した場合は、「環境設定>>拡張機能>AzureSphere」をチェックして、"Azure Sphere: Arm Gnu Path" が GNU Arm Embedded Toolchain インストールディレクトリを識別するようにします。

出力を表示するようにハードウェアを設定する

現時点では、各リアルタイムコアは TX 専用 UART をサポートしています。 RTApps はこの UART を使用して、デバイスからログ出力を送信できます。アプリケーションの開発とデバッグ中は、通常、出力を読み取って表示する方法が必要です。 HelloWorld_RTApp_MT3620_BareMetalサンプルは、アプリケーションが UART に書き込む方法を示しています。

FTDI フレンドなどの USB からシリアルへのアダプターを使用して、リアルタイムコアの UART をコンピューターの USB ポートに接続します。また、出力を表示するには、115200-8-N-1 ターミナル設定 (115200 bps、8 ビット、パリティビットなし、1 ストップビット) でシリアル接続を確立するためのターミナルエミュレーターも必要です。

RTApp からの出力を表示するようにハードウェアを設定するには、次の手順に従います。ピンの場所を特定するには、ハードウェアの製造元のドキュメントを参照する必要があります。 MT3620 リファレンスボード設計 (RDB) ハードウェア (Seeed Studios の MT3620 Dev Kit など) に従うハードウェアを使用している場合は、 RDB インターフェイスヘッダーを確認すると、ピンの場所を特定するのに役立つ場合があります。

USB からシリアルへのアダプターの GND を開発キットの GND に接続します。 MT3620 RDB ハードウェアでは、GND はヘッダー 3、ピン 2 です。
USB からシリアルへのアダプターの RX を開発キットの IOM4-0 TX に接続します。 MT3620 RDB ハードウェアでは、IOM4-0 TX はヘッダー 3、ピン 6 です。
USB からシリアルへのアダプターを開発用コンピューター上の空き USB ポートに接続し、シリアルデバイスが接続されているポートを決定します。
- Windows で、デバイスマネージャーを開始し、[コンテナー別にデバイスを表示>] を選択し、[USB UART] を探します。たとえば、FT232R USB UART は FTDI フレンドアダプターを示します。
- Linux では、次のコマンドを入力します。
```
dmesg | grep ttyUSB
```
  ポートには ttyUSBn という名前を付ける必要があります。 n はポート番号を示します。コマンドに複数の dmesg USB ポートが一覧表示されている場合、接続されているポートは通常、最後の USB ポートに接続済みとして報告されます。たとえば、次の例では、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
```
ターミナルエミュレータープログラムを起動し、アダプターで使用される COM ポートに 115200-8-N-1 ターミナルを開きます。ポートと速度を指定する方法については、ターミナルエミュレーターのドキュメントを参照してください。

開発とデバッグを有効にする

Azure Sphere デバイスでサンプルアプリケーションを構築したり、新しいアプリケーションを開発したりする前に、開発とデバッグを有効にする必要があります。既定では、Azure Sphere デバイスは "ロック" されます。つまり、開発中のアプリケーションを PC から読み込むのは許可せず、アプリケーションのデバッグも許可しません。デバッグ用にデバイスを準備すると、この制限が解除され、デバッグに必要なソフトウェアが読み込まれて、デバイス機能のロックが解除されます。

リアルタイムコアでデバッグするには、 az sphere device enable-development コマンドを使用します。このコマンドは、デバッグのために PC からアプリケーションを受け入れるようにデバイスを構成し、クラウドアプリケーションの更新を許可しない開発デバイスグループにデバイスを割り当てます。アプリケーションの開発とデバッグ中は、クラウドアプリケーションの更新によって開発中のアプリケーションが上書きされないように、デバイスをこのグループに残す必要があります。

Windows では、デバッグサーバーとコアの --enable-rt-core-debugging 種類ごとに必要なドライバーをデバイスに読み込むパラメーターを追加する必要があります。

Windows
Linux

まだログインしていない場合は、Azure Sphere にログインします。
```
az login
```
PowerShell または Windows コマンドプロンプトを使用して、管理者特権でコマンドラインインターフェイスを開きます。パラメーターには --enable-rt-core-debugging 、デバッガー用の USB ドライバーがインストールされるため、管理者特権が必要です。

次のコマンドを入力します。

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

管理者特権が不要になったため、コマンドの完了後にウィンドウを閉じます。ベストプラクティスとして、タスクを実行できる最小限の特権を常に使用する必要があります。

まだログインしていない場合は、Azure Sphere にログインします。
```
az login
```

次のコマンドを入力します。

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

az sphere device enable-development コマンドが失敗した場合は、「Azure Sphere の問題のトラブルシューティング」を参照してください。

サンプルアプリケーションをダウンロードする

InterCore Communications アプリケーションは、次のようにダウンロードできます。

ブラウザーを Microsoft Samples Browser にポイントします。
[Search] ボックスに「Azure Sphere」と入力します。
検索結果から [ Azure Sphere - コア間通信 ] を選択します。
[ ZIP のダウンロード] を選択します。
ダウンロードしたファイルを開き、ローカルディレクトリに展開します。

パートナーアプリケーションをビルドして実行する

Visual Studio を起動します。 [ローカルフォルダーを開く] を選択し、IntercoreComms アプリケーションを抽出したフォルダーに移動します。

大事な

Visual Studio 2022 バージョン 17.1 以降を使用していて、22.02 Azure Sphere リリースより前に IntercoreComms サンプルを抽出した場合は、 CMakeWorkspaceSettings.json ファイルを最上位のプロジェクトフォルダーに追加する必要があります。
MT3620 RDB を使用していない場合は、アプリケーションとハードウェア定義ファイルの両方のapp_manifest.jsonファイルと、ハードウェアに一致する高レベルアプリケーションの CMakeLists.txt ファイルを更新します。
CMake の生成が自動的に開始されない場合は、CMakeLists.txt ファイルを選択します。
Visual Studio では、出力>の表示>出力の表示元: CMake 出力には、メッセージCMake generation startedと CMake generation finishedが表示されます。
[Build All]\(すべてビルド\) を>選択します。メニューが表示されない場合は、ソリューションエクスプローラーを開き、CMakeLists.txt ファイルを右クリックして、[ビルド] を選択します。 IntercoreComms_HL & IntercoreComms RT アプリケーションの出力場所が [出力 ] ウィンドウに表示されます。
[スタートアップ項目の IntercoreComms (すべてのコア)]を選択します>。
[ デバッグ]>を選択するか、F5 キーを押してアプリケーションをデプロイしてデバッグします。

[ 出力 ] ウィンドウの [ 出力の選択] メニューで 、[ デバイスの出力] を選択します。 [ 出力] ウィンドウには、アプリケーションの大まかな出力が表示されます。

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

接続されたターミナルエミュレーターには、リアルタイム対応プログラムからの出力が表示されます。

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

デバッガーを使用してブレークポイントを設定し、変数を検査し、他のデバッグタスクを試します。

Visual Studio Code で、IntercoreComms アプリケーションを抽出したフォルダーを開きます。 Visual Studio Code は intercore.code-workspace ファイルを検出し、ワークスペースを開くかどうかを確認します。 [ワークスペースを開く] を選択して、リアルタイムアプリケーションと高レベルアプリケーションの両方を一度に開きます。
MT3620 RDB を使用していない場合は、アプリケーションとハードウェア定義ファイルの両方のapp_manifest.jsonファイルと、ハードウェアに一致する高レベルアプリケーションの CMakeLists.txt ファイルを更新します。
F5 キーを押してデバッガーを起動します。プロジェクトが以前にビルドされていない場合、またはファイルが変更され、再構築が必要な場合、Visual Studio Code はデバッグを開始する前にプロジェクトをビルドします。
Azure Sphere の出力ウィンドウに "イメージのデプロイ... " が表示されます。SDK とコンパイラへのパスが続きます。

出力ウィンドウには、アプリケーションの大まかな出力が表示されます。

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

接続されたターミナルエミュレーターには、リアルタイム対応プログラムからの出力が表示されます。

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

Visual Studio Code デバッグ機能を使用して、ブレークポイントの設定、変数の検査、その他のデバッグタスクの試行を行います。

トラブルシューティング

OpenOCD が接続する前に、アプリケーションの実行が開始される可能性があります。その結果、コードの早い段階で設定されたブレークポイントが見逃される可能性があります。この簡単な回避策は、OpenOCD が接続されるまでアプリの起動を遅らせることです。

アプリケーションエントリポイント RTCoreMain の先頭に次のコードを挿入します。これにより、変数fが true に設定されるまで、アプリケーションはループにwhile入り続けます。
```
static _Noreturn void RTCoreMain(void)
{
  .
  .
  .
 volatile bool f = false;
 while (!f) {
    // empty.
 }
  .
  .
  .
}
```
F5 キーを押してデバッグでアプリを起動し、実行に分割します。
[ ローカル ] デバッグウィンドウで、の f 値を 0 から 1 に変更します。
通常どおりにコードをステップ実行します。

CLI を使用してビルドする場合は、まずリアルタイム対応アプリケーションをビルドしてデプロイしてから、高レベルのアプリケーションをビルドしてデプロイします。

リアルタイム対応アプリケーションを構築してデプロイする

IntercoreComms アプリケーションを抽出したフォルダーに移動し、IntercoreComms/IntercoreComms_RTApp_MT3620_BareMetal フォルダーを選択します。
app_manifest.json ファイルを開き、上位レベルのアプリのコンポーネント ID が AllowedApplicationConnections 機能に表示されていることを確認します。
PowerShell、Windows コマンドプロンプト、または Linux コマンドシェルを使用して、コマンドラインインターフェイスを開きます。プロジェクトビルドディレクトリに移動します。
プロジェクトビルドディレクトリから、コマンドプロンプトで、次のパラメーターを指定して CMake を実行します。
```
cmake --preset <preset-name> <source-path>
```
- --preset <preset-name>
  
  CMakePresets.jsonで定義されているビルド構成プリセット名。
- --build <cmake-path>
  
  CMake キャッシュを含むバイナリディレクトリ。たとえば、Azure Sphere サンプルで CMake を実行する場合、ビルドコマンドはになります cmake --build out/ARM-Debug。
- <source-path>
  
  サンプルアプリケーションのソースファイルを含むディレクトリのパス。この例では、Azure Sphere サンプルリポジトリが AzSphere というディレクトリにダウンロードされました。
  
  CMake パラメーターはスペースで区切られます。行継続文字 (^ for Windows コマンドライン、\ for Linux コマンドライン、または ' for PowerShell) は読みやすくするために使用できますが、必須ではありません。
次の例は、IntercoreComms RTApp の CMake コマンドを示しています。
- Windows
- Linux
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"
```
```
 cmake \
--preset "ARM-Debug" \
 ./AzSphere/azure-sphere-samples/Samples/IntercoreComms/IntercoreComms_RTApp_MT3620_BareMetal
```
プロジェクトビルドディレクトリから、コマンドプロンプトで Ninja を実行してアプリケーションをビルドし、イメージパッケージファイルを作成します。
```
ninja -C out/ARM-Debug
```
Ninja は、結果のアプリケーションファイルと .imagepackage ファイルを指定されたディレクトリに配置します。

次のコマンドを使用して、CMake を介して Ninja を呼び出すこともできます。
```
cmake --build out/<binary-dir>
```
CMake キャッシュを含むバイナリディレクトリに設定 <binary-dir> します。たとえば、Azure Sphere サンプルで CMake を実行する場合、ビルドコマンドはになります cmake --build out/ARM-Debug。

特に CMake コマンドに変更を加えてからトラブルシューティングを行う場合は、ビルド全体を削除してやり直してください。
デバイスに既にデプロイされているアプリケーションを削除します。
```
az sphere device sideload delete
```
プロジェクトビルドディレクトリから、コマンドプロンプトで、ninja によって作成されたイメージパッケージを読み込みます。
```
az sphere device sideload deploy --image-package <path-to-imagepackage>
```
アプリケーションが読み込まれた直後に、アプリケーションの実行が開始されます。
イメージのコンポーネント ID を取得します。
```
az sphere image-package show --image-package <path-to-imagepackage>
```
コマンドは、イメージパッケージのすべてのメタデータを返します。アプリケーションのコンポーネント ID は、[アプリケーションイメージの種類] の [ID] セクションに表示されます。例えば：
```
...
  "Identity": {
    "ComponentId": "<component-id>",
    "ImageId": "<image-id>",
    "ImageType": "Application"
  },
...
```

高度なアプリケーションをビルドしてデプロイする

IntercoreComms アプリケーションを抽出したフォルダーに移動し、IntercoreComms/IntercoreComms_HighLevelApp フォルダーを選択します。
app_manifest.json ファイルを開き、RTApp のコンポーネント ID が AllowedApplicationConnections 機能に表示されていることを確認します。
PowerShell、Windows コマンドプロンプト、または Linux コマンドシェルを使用して、コマンドラインインターフェイスを開きます。プロジェクトビルドディレクトリに移動します。
プロジェクトビルドディレクトリから、コマンドプロンプトで、次のパラメーターを指定して CMake を実行します。
```
cmake --preset <preset-name> <source-path>
```
- --preset <preset-name>
  
  CMakePresets.jsonで定義されているビルド構成プリセット名。
- --build <cmake-path>
  
  CMake キャッシュを含むバイナリディレクトリ。たとえば、Azure Sphere サンプルで CMake を実行する場合、ビルドコマンドはになります cmake --build out/ARM-Debug。
- <source-path>
  
  サンプルアプリケーションのソースファイルを含むディレクトリのパス。この例では、Azure Sphere サンプルリポジトリが AzSphere というディレクトリにダウンロードされました。
  
  CMake パラメーターはスペースで区切られます。行継続文字 (^ for Windows コマンドライン、\ for Linux コマンドライン、または ' for PowerShell) は読みやすくするために使用できますが、必須ではありません。
次の例は、IntercoreComms の高レベルアプリケーションの CMake コマンドを示しています。
- Windows
- Linux
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"
```
```
 cmake \
 --preset "ARM-Debug" \
 ./AzSphere/azure-sphere-samples/Samples/IntercoreComms/IntercoreComms_HighLevelApp
```
プロジェクトビルドディレクトリから、コマンドプロンプトで Ninja を実行してアプリケーションをビルドし、イメージパッケージファイルを作成します。
```
ninja -C out/ARM-Debug
```
Ninja は、結果のアプリケーションファイルと .imagepackage ファイルを指定されたディレクトリに配置します。

次のコマンドを使用して、CMake を介して Ninja を呼び出すこともできます。
```
cmake --build out/<binary-dir>
```
CMake キャッシュを含むバイナリディレクトリに設定 <binary-dir> します。たとえば、Azure Sphere サンプルで CMake を実行する場合、ビルドコマンドはになります cmake --build out/ARM-Debug。

特に CMake コマンドに変更を加えてからトラブルシューティングを行う場合は、ビルド全体を削除してやり直してください。
プロジェクトビルドディレクトリから、コマンドプロンプトで、ninja によって作成されたイメージパッケージを読み込みます。
```
az sphere device sideload deploy --image-package <package-name>
```
アプリケーションが読み込まれた直後に、アプリケーションの実行が開始されます。
イメージのコンポーネント ID を取得します。
```
az sphere image-package show --image-package <path-to-imagepackage>
```
コマンドは、イメージパッケージのすべてのメタデータを返します。アプリケーションのコンポーネント ID は、[アプリケーションイメージの種類] の [ID] セクションに表示されます。例えば：
```
...
  "Identity": {
    "ComponentId": "<component-id>",
    "ImageId": "<image-id>",
    "ImageType": "Application"
  },
...
```

デバッグを有効にしてパートナーアプリケーションを実行する

リアルタイムアプリケーションが実行されている場合は停止します。
```
az sphere device app stop --component-id <component id>
```
デバッグのためにアプリケーションを再実行します。
```
az sphere device app start -- --debug-mode true --component-id <component id>
```
このコマンドは、アプリケーションが実行されているコアを返します。
```
  <component id>
  App state: running
  Core        : Real-time 0
```
アプリケーションがビルドされた sysroot の Openocd フォルダーに移動します。 sysroots は、Azure Sphere SDK のインストールフォルダーにインストールされます。たとえば、Windows では、フォルダーは既定で Linux のと /opt/azurespheresdk/Sysroots/*sysroot*/tools/sysroots/x86_64-pokysdk-linuxで C:\Program Files (x86)\Microsoft Azure Sphere SDK\Sysroots\*sysroot*\tools\openocd インストールされます。

次の例に示すようにを実行 openocd します。この例では、アプリがコア 0 で実行されていることを前提としています。アプリがコア 1 で実行されている場合は、"targets io0" を "targets io1" に置き換えます。

Windows
Linux

   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"

   ./usr/bin/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"

新しい Azure Sphere コマンドプロンプト (Windows Azure Sphere クラシック CLI)、標準コマンドプロンプト、PowerShell (Windows Azure CLI)、またはターミナルウィンドウ (Linux) を開きます。
リアルタイム対応アプリケーション .out ファイルを含むフォルダーに移動し、GNU Arm Embedded Toolchain の一部である start arm-none-eabi-gdbに移動します。
- Windows
- Linux
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
```
/opt/gnu-arm-toolchain/arm-none-eabi-gdb IntercoreComms_RTApp_MT3620_BareMetal.out
OpenOCD サーバーは、:4444 で GDB サーバーインターフェイスを提供します。デバッグのターゲットを設定します。

target remote :4444
リアルタイム対応アプリケーションに対して gdb コマンドを実行できるようになりました。関数 HandleSendTimerDeferred にブレークポイントを追加します。
```
break HandleSendTimerDeferred
```
接続されたターミナルエミュレーターは、リアルタイム対応アプリケーションからの出力を表示する必要があります。
新しい Azure Sphere コマンドプロンプト (Windows Azure Sphere クラシック CLI)、標準コマンドプロンプト、PowerShell (Windows Azure CLI)、またはターミナルウィンドウ (Linux) を開きます。
高度なアプリケーション .imagepackage ファイルを含むフォルダーに移動します。
高度なアプリケーションが実行されている場合は停止します。
```
az sphere device app stop --component-id <component id>
```

デバッグを使用して、高度なアプリケーションを再開します。

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

ターミナルエミュレーターを開き、ポート 2342 で 192.168.35.2 への Telnet または TCP 接続を確立して、上位レベルのアプリの出力を表示します。
次のコマンドを使用して gdb を起動します。
- Windows
- Linux
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
```
```
/opt/azurespheresdk/Sysroots/*sysroot*/tools/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-musleabi/arm-poky-linux-musleabi-gdb IntercoreComms_HighLevelApp.out
```
メモ

Azure Sphere SDK には複数の sysroot が付属しているため、「アプリケーションランタイムバージョン、sysroots、Beta API」で説明されているように、アプリケーションが異なる API セットをターゲットにすることができます。 sysroots は、 Sysroots の Azure Sphere SDK インストールフォルダーにインストールされます。
リモートデバッグターゲットを、ポート 2345 の IP アドレス 192.168.35.2 に設定します。

target remote 192.168.35.2:2345
関数 SendMessageToRTApp にブレークポイントを追加します。

break SendMessageToRTApp
「」と入力 c して続行し、Telnet/TCP ターミナルの出力を確認してから、リアルタイムアプリケーションデバッグセッションを含むコマンドプロンプトまたはターミナルウィンドウに切り替えます。
「」と入力 c して続行し、接続されたシリアルセッションの出力を確認します。

デバッグセッション間でやり取りし、リアルタイム対応アプリケーションと高レベルアプリケーションを切り替えることができます。次のような出力が 2 つの出力ウィンドウに表示されます。

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

各デバッグセッションを終了するには、gdb プロンプトで「」と入力 q します。

次の手順

高レベルおよびリアルタイム対応アプリケーションの追加サンプルを調べる
Azure Sphere アプリケーションの詳細
Azure Sphere 開発環境の詳細

チュートリアル: パートナー アプリケーションのビルドとデバッグ

前提 条件