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

[アーティクル]
09/27/2024

重要

これは Azure Sphere (レガシ) のドキュメントです。 Azure Sphere (レガシ) は 2027 年 9 月 27 日に再提供されておりユーザーは現時点で Azure Sphere (統合) に移行する必要があります。 TOC の上にある Version セレクターを使用して、Azure Sphere (統合) のドキュメントを表示します。

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

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

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

重要

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

前提条件

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

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

Visual Studio 用の Azure Sphere 拡張機能をインストール。

Azure Sphere SDK for Windows または Linux 用のをインストールする
テナントを選択してデバイスを要求する
ネットワークを構成し、デバイス OS を更新する

GNU Arm 埋め込みツールチェーンをインストールします

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 はツールチェーンを検索し、インストールしたバージョンを見つける必要があります。ツールチェーンに関連するビルドの問題が発生した場合は、 Preferences>Settings>Extensions>AzureSphere を調べて、"Azure Sphere: Arm Gnu Path" が GNU Arm Embedded Toolchain インストールディレクトリを識別していることを確認します。

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

現在、各リアルタイムコアでは TX 専用の UART がサポートされています。 RTApps は、この UART を使用してデバイスからログ出力を送信します。アプリケーションの開発とデバッグの際には、一般に、出力を読み取って表示する手段が必要となります。 HelloWorld_RTApp_MT3620_BareMetal サンプルは、アプリケーションがどのように UART に書き込むかを示しています。

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

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

USB シリアル変換アダプターの GND をお使いの開発キットの GND に接続します。 MT3620 RDB ハードウェアでは、GND はヘッダー3、ピン 2 です。
USB シリアル変換アダプターの RX をお使いの開発キットの IOM4-0 TX に接続します。 MT3620 RDB ハードウェアでは、IOM4-0 TX はヘッダー3、ピン 6 です。
USB からシリアルへのアダプターを開発用コンピューター上の空き USB ポートに接続し、シリアルデバイスが接続されているポートを決定します。
- Windows でデバイスマネージャーを起動し、View>Devices by container を選択し、"USB UART" を探します。たとえば、FT232R USB UART は FTDI フレンドアダプターを示します。
- Linux では、次のコマンドを入力します。
```
dmesg | grep ttyUSB
```
  ポートには ttyUSBn という名前を付ける必要があります。この n はポート番号です。 dmesg コマンドが複数の 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 デバイス用の新しいアプリケーションを開発したりするには、その前に、開発とデバッグを有効にする必要があります。既定では、Azure Sphere デバイスは "ロックされています"。つまり、開発中のアプリケーションを PC から読み込むことはできず、アプリケーションのデバッグは許可されません。デバッグ用にデバイスを準備すると、この制限がなくなり、デバッグに必要なソフトウェアが読み込まれ、「デバイス機能と通信」で説明されているように、デバイスの機能がロック解除されます。

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

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

Windows
Linux

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

Azure Sphere クラシック CLI は廃止されます。 Azure Sphere (Integrated) を使用することをお勧めします。
管理者特権はもう必要ないので、コマンドが完了したらウィンドウを閉じます。ベストプラクティスとして、常に、タスクを実行できる最も低い特権を使用する必要があります。

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

サンプルアプリケーションのダウンロード

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

ブラウザーを Microsoft Samples Browser をポイントします。
検索ボックスに「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 では、 View>Output>Show output from: CMake 出力には、メッセージの CMake generation started と CMake generation finishedが表示されます。
Build>Build All を選択します。メニューが表示されない場合は、ソリューションエクスプローラーを開き、CMakeLists.txt ファイルを右クリックし、Build を選択します。 IntercoreComms_HL > IntercoreComms RT アプリケーションの出力場所が Output ウィンドウに表示されます。
スタートアップ項目の選択>IntercoreComms (すべてのコア)を選択します。
Debug>Debugを選択するか、F5 キーを押してアプリケーションをデプロイしてデバッグします。

Output ウィンドウで、[出力の選択] メニューデバイス出力選択。 Output ウィンドウには、高レベルのアプリケーション出力が表示されます。

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 の出力ウィンドウに、"Deploying image..."$画像のデプロイ中...$ に続いて 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 キーを押してデバッグでアプリを起動し、実行に中断します。
Locals デバッグウィンドウで、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 パラメーターはスペースで区切られます。行継続文字 (Windows コマンドラインの場合は ^、Linux コマンドラインの場合は \、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>
```
<binary-dir> CMake キャッシュを含むバイナリディレクトリに設定します。たとえば、Azure Sphere サンプルで CMake を実行すると、ビルドコマンドが cmake --build out/ARM-Debugされます。

特に CMake コマンドを変更した後にトラブルシューティングを行う場合は、ビルド全体を削除してから、やり直してください。
デバイスに既にデプロイされているアプリケーションをすべて削除します。
```
azsphere device sideload delete
```
プロジェクトビルドディレクトリから、コマンドプロンプトで、ninja によって作成されたイメージパッケージを読み込みます。
- Azure Sphere CLI
- Azure Sphere クラシック CLI
```
azsphere device sideload deploy --image-package <path-to-imagepackage>
```
```
azsphere device sideload deploy --imagepackage <path-to-imagepackage>
```
Note

Azure Sphere クラシック CLI は廃止されます。 Azure Sphere (Integrated) を使用することをお勧めします。
アプリケーションは、読み込まれた直後に実行が開始されます。
イメージのコンポーネント ID を取得します。
- Azure Sphere CLI
- Azure Sphere クラシック CLI
```
azsphere image-package show --image-package <path-to-imagepackage>
```
```
azsphere image-package show --filepath <path-to-imagepackage>
```
Note

Azure Sphere クラシック CLI は廃止されます。 Azure Sphere (Integrated) を使用することをお勧めします。
このコマンドは、イメージパッケージのすべてのメタデータを返します。アプリケーションのコンポーネント ID は、イメージの種類 Application の Identity セクションに表示されます。次に例を示します。
```
Image package metadata:
Section: Identity
Image Type:           Application
Component ID:         <component id>
Image ID:             <image id>
```

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

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 パラメーターはスペースで区切られます。行継続文字 (Windows コマンドラインの場合は ^、Linux コマンドラインの場合は \、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>
```
<binary-dir> CMake キャッシュを含むバイナリディレクトリに設定します。たとえば、Azure Sphere サンプルで CMake を実行すると、ビルドコマンドが cmake --build out/ARM-Debugされます。

特に CMake コマンドを変更した後にトラブルシューティングを行う場合は、ビルド全体を削除してから、やり直してください。
プロジェクトビルドディレクトリから、コマンドプロンプトで、ninja によって作成されたイメージパッケージを読み込みます。
- Azure Sphere CLI
- Azure Sphere クラシック CLI
```
azsphere device sideload deploy --image-package <package-name>
```
```
azsphere device sideload deploy --imagepackage <package-name>
```
Note

Azure Sphere クラシック CLI は廃止されます。 Azure Sphere (Integrated) を使用することをお勧めします。
アプリケーションは、読み込まれた直後に実行が開始されます。
イメージのコンポーネント ID を取得します。
- Azure Sphere CLI
- Azure Sphere クラシック CLI
```
azsphere image-package show --image-package <path-to-imagepackage>
```
```
azsphere image-package show --filepath <path-to-imagepackage>
```
Note

Azure Sphere クラシック CLI は廃止されます。 Azure Sphere (Integrated) を使用することをお勧めします。
このコマンドは、イメージパッケージのすべてのメタデータを返します。アプリケーションのコンポーネント ID は、イメージの種類 Application の Identity セクションに表示されます。次に例を示します。
```
Image package metadata:
  Section: Identity
    Image Type:           Application
    Component ID:         <component id>
    Image ID:             <image id>
```

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

リアルタイムアプリケーションが実行されている場合は停止します。
- Azure Sphere CLI
- Azure Sphere クラシック CLI
```
azsphere device app stop --component-id <component id>
```
```
azsphere device app stop --componentid <component id>
```
Note

Azure Sphere クラシック CLI は廃止されます。 Azure Sphere (Integrated) を使用することをお勧めします。
デバッグのためにアプリケーションを再開します。
- Azure Sphere CLI
- Azure Sphere クラシック CLI
```
azsphere device app start --component-id <component id>
```
```
azsphere device app start --componentid <component id>
```
Note

Azure Sphere クラシック CLI は廃止されます。 Azure Sphere (Integrated) を使用することをお勧めします。
このコマンドは、アプリケーションが実行中のコアを返します。
```
  <component id>
  App state: running
  Core        : Real-time 0
```
アプリケーションのビルドに使用された、Openocd フォルダー内の sysroot に移動します。 sysroot は、Azure Sphere SDK インストールフォルダーにインストールされます。たとえば、Windows では、フォルダーは既定で C:\Program Files (x86)\Microsoft Azure Sphere SDK\Sysroots\*sysroot*\tools\openocd にインストールされ、Linux では /opt/azurespheresdk/Sysroots/*sysroot*/tools/sysroots/x86_64-pokysdk-linux にインストールされます。

次の例に示すように 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 Sphere CLI)、またはターミナルウィンドウ (Linux) を開きます。
リアルタイム対応アプリケーション .out ファイルが含まれているフォルダーに移動し、GNU Arm Embedded Toolchain の一部である 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 Sphere CLI)、またはターミナルウィンドウ (Linux) を開きます。
高度なアプリケーション .imagepackage ファイルを含むフォルダーに移動します。
高度なアプリケーションが実行されている場合は停止します。
- Azure Sphere CLI
- Azure Sphere クラシック CLI
```
azsphere device app stop --component-id <component id>
```
```
azsphere device app stop --componentid <component id>
```
Note

Azure Sphere クラシック CLI は廃止されます。 Azure Sphere (Integrated) を使用することをお勧めします。
デバッグを使用して、高度なアプリケーションを再開します。
- Azure Sphere CLI
- Azure Sphere クラシック CLI
```
azsphere device app start --component-id <component id> --debug-mode
```
```
azsphere device app start --componentid <component id> --debug
```
Note

Azure Sphere クラシック CLI は廃止されます。 Azure Sphere (Integrated) を使用することをお勧めします。
ターミナルエミュレーターを開きポート 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
```
Note

Azure Sphere SDK には複数の sysroots が付属しているため、アプリケーションは、 Application ランタイムバージョン、sysroots、および Beta API で説明されているように、異なる API セットをターゲットにすることができます。 sysroot は、Azure Sphere SDK インストールフォルダーの Sysroots の下にインストールされます。
リモートデバッグターゲットをポート 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 開発環境の詳細を確認する

次の方法で共有

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

前提条件

GNU Arm 埋め込みツールチェーンをインストールします

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

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

サンプルアプリケーションのダウンロード

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

トラブルシューティング

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

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

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

次のステップ

フィードバック

その他のリソース

次の方法で共有

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

前提条件

GNU Arm 埋め込みツールチェーンをインストールします

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

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

サンプル アプリケーションのダウンロード

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

トラブルシューティング

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

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

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

次のステップ

フィードバック

その他のリソース

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

サンプルアプリケーションのダウンロード

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

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