翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # エラーのトラブルシューティング 各テストスイートの実行には一意の実行 ID があります。この ID を使用して、`results` ディレクトリに `results/execution-id` という名前のフォルダを作成します。テストグループ別のログは `results/execution-id/logs` ディレクトリにあります。IDT for FreeRTOS コンソールの出力を使用して、失敗したテストケースの実行 ID、テストケース ID、およびテストグループ ID を検索し、そのテストケースの `results/execution-id/logs/test_group_id__test_case_id.log` という名前のログファイルを開きます。このファイルの情報には以下が含まれます。 + すべてのビルドおよびフラッシュコマンド出力。 + テスト実行出力。 + 詳細な IDT for FreeRTOS コンソール出力。 トラブルシューティングに次のワークフローをお勧めします。 1. 「*user/role* is not authorized to access this resource (user/role にこのリソースにアクセスする権限がありません)」というエラーが表示された場合、[AWS アカウントの作成と設定](dev-tester-prereqs.md#config-aws-account) で指定したようにアクセス許可を設定していることを確認します。 1. コンソール出力を読み取り、実行 UUID や現在実行中のタスクなどの情報を確認します。 1. 各テストのエラーステートメントについて `FRQ_Report.xml` ファイルを確認します。このディレクトリには、各テストグループの実行ログが含まれています。 1. `/results/execution-id/logs` にあるログファイルを確認します。 1. 以下の問題領域のいずれかを調べてください。 + `/configs/` フォルダの JSON 設定ファイルなどのデバイス設定。 + デバイスインターフェイス。ログを確認して、どのインターフェイスが失敗しているかを判断します。 + デバイスツール。デバイスをビルドおよびフラッシュするためのツールチェーンがインストールされ、正しく設定されていることを確認します。 + FRQ 1.x.x では、FreeRTOS ソースコードのクローンされたクリーンなバージョンが使用可能であることを確認します。FreeRTOS リリースは FreeRTOS バージョンに従ってタグ付けされます。そのコードの特定のバージョンのクローンを作成するには、次のコマンドを使用します。 ``` git clone --branch version-number https://github.com/aws/amazon-freertos.git cd amazon-freertos git submodule update --checkout --init --recursive ``` ## デバイス設定のトラブルシューティング IDT for FreeRTOS を使用するときは、バイナリを実行する前に正しい設定ファイルを所定の場所に配置する必要があります。解析エラーや設定エラーが発生する場合は、まず環境に適した設定テンプレートを見つけて使用してください。これらのテンプレートは、`IDT_ROOT/configs` ディレクトリにあります。 それでも問題が解決されない場合は、次のデバッグプロセスを参照してください。 ### どこを見ればよいか まず、コンソール出力を読み取って、このドキュメントで `execution-id` として参照される実行 UUID などの情報を見つけます。 次に、`/results/execution-id` ディレクトリにある `FRQ_Report.xml` ファイルを確認します。このファイルには、実行されたすべてのテストケースと、各障害のエラースニペットがあります。すべての実行ログを取得するには、各テストケースの `/results/execution-id/logs/test_group_id__test_case_id.log` ファイルを探します。 ### IDT エラーコード IDT for FreeRTOS によって生成されるエラーコードを次の表に示します。 | エラーコード | エラーコード名 | 考えられる根本原因 | トラブルシューティング | | --- | --- | --- | --- | | 201 | InvalidInputError | `device.json`、`config.json`、または `userdata.json` のフィールドがないか、正しくない形式です。 | 必須フィールドが欠落していないこと、およびリストされたファイルで必須の形式であることを確認します。詳細については、[マイクロコントローラーボードの最初のテスト](qual-steps.md) を参照してください。 | | 202 | ValidationError | `device.json`、`config.json`、または `userdata.json` のフィールドに無効な値が含まれています。 | レポートのエラーコードの右側にあるエラーメッセージを確認します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/dt-afr-troubleshooting.html) | | 203 | CopySourceCodeError | 指定されたディレクトリに FreeRTOS ソースコードをコピーできません。 | 以下の項目について確認してください。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/dt-afr-troubleshooting.html) | | 204 | BuildSourceError | FreeRTOS ソースコードをコンパイルできません。 | 以下の項目について確認してください。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/freertos/latest/userguide/dt-afr-troubleshooting.html) | | 205 | FlashOrRunTestError | IDT FreeRTOS が DUT で FreeRTOS をフラッシュまたは実行できません。 | `userdata.json` ファイルの下にある `flashTool` 情報が正しいことを確認します。詳細については、[ビルド、フラッシュ、テスト設定を設定する](cfg-dt-ud.md) を参照してください。 | | 2.0.6 | StartEchoServerError | IDT FreeRTOS が、Wi-Fi またはセキュアソケットテストでエコーサーバーを起動できません。 | `userdata.json` ファイルの `echoServerConfiguration` で設定されたポートが使用中でないこと、ファイアウォールまたはネットワーク設定によってブロックされていないことを確認します。 | ### 設定ファイルの解析エラーのデバッグ 場合によっては、JSON 設定のタイプミスが解析エラーにつながることがあります。ほとんどの場合、JSON ファイルで括弧やカンマ、引用符を忘れたことが原因です。IDT for FreeRTOS は、JSON 検証を行い、デバッグ情報を出力します。エラーが発生した行、構文エラーの行番号と列番号が出力されます。この情報だけでエラーの修正が可能なはずですが、それでもエラーを特定できない場合は、IDE、テキストエディタ (Atom、Sublime など)、またはオンラインツール (JSONLint など) を使って手動で検証を行います。 ### テスト結果の解析エラーのデバッグ [FreeRTOS-Libraries-Integration-Tests](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests) からのテストグループ (**FullTransportInterfaceTLS, FullPKCS11\$1Core、FullPKCS11\$1Onboard\$1ECC、FullPKCS11\$1Onboard\$1RSA、FullPKCS11\$1PreProvisioned\$1ECC、FullPKCS11\$1PreProvisioned\$1RSA**、**OTACore** など) を実行している間、IDT for FreeRTOS はシリアル接続を使用してテストデバイスからのテスト結果を解析します。場合によっては、デバイス上の余分なシリアル出力がテスト結果の解析を妨げることがあります。 上記のケースでは、関係のないデバイス出力から派生した文字列など、テストケースの失敗に関する奇妙な理由が出力されます。IDT for FreeRTOS テストケースのログファイル (IDT for FreeRTOS がテスト中に受信したすべてのシリアル出力を含む) には、次の内容が表示される場合があります。 ``` TEST(Full_PKCS11_Capabilities, PKCS11_Capabilities) PASS ``` 上記の例では、関連のないデバイス出力により、IDT for FreeRTOS はテスト結果である **PASS** を検出できません。 次の点を確認して、最適なテストを行ってください。 + デバイスで使用されているロギングマクロがスレッドセーフであることを確認してください。詳細については、「[Implementing the library logging macros](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-library-logging-macros.html)」を参照してください。 + テスト中は、シリアル接続への出力が最小限になるようにしてください。ロギングマクロが適切にスレッドセーフであっても、テスト結果はテスト中に別々の呼び出しで出力されるため、他のデバイス出力は問題になる可能性があります。 IDT for FreeRTOS のテストケースログでは、次のような中断のないテスト結果出力が表示されることが理想的です。 ``` ---------STARTING TESTS--------- TEST(Full_OTA_PAL, otaPal_CloseFile_ValidSignature) PASS TEST(Full_OTA_PAL, otaPal_CloseFile_InvalidSignatureBlockWritten) PASS ----------------------- 2 Tests 0 Failures 0 Ignored ``` ### 整合性チェック失敗のデバッグ FRQ 1.x.x バージョンの FreeRTOS を使用している場合は、以下の整合性チェックが適用されます。 FreeRTOSIntegrity テストグループを実行して失敗した場合は、まず、`freertos` ディレクトリのファイルのいずれかを変更していないか確認します。変更しておらず、問題が解消しない場合は、正しいブランチを使用していることを確認してください。IDT の `list-supported-products` コマンドを実行すると、使用する必要のある `freertos` リポジトリのタグ付きブランチを検索できます。 `freertos` リポジトリの正しいタグ付きブランチのクローンを作成しても問題が解消しない場合は、`submodule update` コマンドも実行したかどうかを確認します。`freertos` リポジトリのクローンワークフローは次のとおりです。 ``` git clone --branch version-number https://github.com/aws/amazon-freertos.git cd amazon-freertos git submodule update --checkout —init —recursive ``` 整合性チェッカーが検索するファイルのリストは、`freertos` ディレクトリの `checksums.json` ファイルにあります。FreeRTOS の移植でファイルやフォルダの構造が変更されていないか確認するには、`checksums.json` ファイルの「`exhaustive`」と「`minimal`」セクションに記載されているファイルが変更されていないことを確認します。SDK を設定して実行するには、「`minimal`」セクションのファイルが変更されていないことを確認します。 SDK で IDT を実行する場合で、`freertos` ディレクトリ内のファイルを変更した場合、`userdata` ファイルの SDK が正しく設定されていることを確認します。それ以外の場合、整合性チェッカーは `freertos` ディレクトリ内のすべてのファイルを検証します。 ### FullWiFi テストグループ失敗のデバッグ FRQ 1.x.x を使用していて FullWiFi テストグループでエラーが発生し、「`AFQP_WiFiConnectMultipleAP`」テストで失敗する場合、両方のアクセスポイントが IDT を実行するホストコンピュータと同じサブネット内にない可能性があります。両方のアクセスポイントが IDT を実行するホストコンピュータと同じサブネット内にあることを確認してください。 ### 「必須パラメータが見つからない」エラーのデバッグ IDT for FreeRTOS には新機能が追加されているため、設定ファイルに変更が生じる可能性があります。古い設定ファイルを使用すると、設定が破損する可能性があります。このような場合は、`results/execution-id/logs` ディレクトリにある `test_group_id__test_case_id.log` ファイルに、すべての不足しているパラメータが明示的に一覧表示されます。IDT for FreeRTOS では、JSON 設定ファイルのスキーマを検証し、最新のサポートされているバージョンが使用されていることを確認します。 ### 「テストを開始できなかった」エラー テストの開始中の障害を示唆するエラーが生じることがあります。原因はいくつか考えられるため、以下が正しいことを確認してください。 + 実行コマンドに含めたプール名が実際に存在することを確認します。この名前は、`device.json` ファイルから直接参照されます。 + プール内のデバイスの設定パラメータが正しいことを確認します。 ### 「テスト結果の開始が見つからない」エラーのデバッグ IDT がテスト対象のデバイスによって出力された結果を解析しようとすると、エラーが発生する場合があります。原因はいくつか考えられるため、以下の事項を確認して修正してください。 + テスト対象のデバイスがホストマシンに安定して接続していることを確認します。これらのエラーが発生するテストのログファイルで IDT が何を受信しているかを確認できます。 + FRQ 1.x.x を使用しており、テスト対象のデバイスが低速なネットワークまたはその他のインターフェイスを介して接続されている場合、または FreeRTOS テストグループのログで「---------STARTING TESTS---------」フラグと他の FreeRTOS テストグループの出力が見つからない場合は、userdata 設定で `testStartDelayms` の値を増やしてみてください。詳細については、「[ビルド、フラッシュ、テスト設定を設定する](cfg-dt-ud.md)」を参照してください。 ### 「Test failure:expected \$1\$1 results but saw \$1\$1\$1」エラーのデバッグ テスト中に、テストの失敗を示すエラーが表示される場合があります。テストで一定数の結果が期待されているにもかかわらず、テスト中にその結果を確認できません。一部の FreeRTOS テストが、IDT がデバイスからの出力を確認する前に実行されています。このエラーが表示された場合は、*userdata* 設定の `testStartDelayms` 値を増やしてみてください。詳細については、「[ビルド、フラッシュ、テスト設定を設定する](lts-cfg-dt-ud.md)」を参照してください。 ### 「\$1\$1\$1\$1\$1\$1\$1\$1 was unselected due to ConditionalTests constraints」エラーのデバッグ これは、テストと互換性のないデバイスプールでテストを実行していることを意味します。これは、OTA E2E テストで発生することがあります。例えば、`OTADataplaneMQTT` テストグループを実行する際に、`device.json` 設定ファイルで OTA に **No** を選択したり、`OTADataPlaneProtocol` に **HTTP** を選択したりした場合などです。実行するテストグループは、`device.json` で選択した機能と一致している必要があります。 ### デバイス出力のモニタリング中の IDT タイムアウトのデバッグ IDT は、さまざまな理由でタイムアウトすることがあります。テストのデバイス出力モニタリングフェーズ中にタイムアウトが発生し、その結果を IDT のテストケースログ内で確認できる場合は、結果が IDT によって誤って解析されたことを意味します。その理由の 1 つとして、テスト結果の途中にインターリーブされたログメッセージが入っていることが考えられます。このような場合は、「[FreeRTOS 移植ガイド](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting-ota.html)」を参照して、UNITY ログの設定方法の詳細を確認してください。 デバイス出力モニタリング中にタイムアウトになるもう 1 つの理由として、TLS テストケースが 1 回失敗するとデバイスが再起動されることが考えられます。その後、デバイスはフラッシュされたイメージを実行し、これによって無限ループが発生します。これはログで確認できます。これが発生した場合は、テストに失敗した後にデバイスが再起動しないようにしてください。 ### 「リソースにアクセスする権限がない」エラー 「*ユーザー/ロール*には、このリソースにアクセスする権限がありません」エラーがターミナル出力または `/results/execution-id/logs` の下の `test_manager.log` ファイルに表示される場合があります。この問題を解決するには、`AWS IoTDeviceTesterForFreeRTOSFullAccess` 管理ポリシーをテストユーザーにアタッチします。詳細については、「[AWS アカウントの作成と設定](dev-tester-prereqs.md#config-aws-account)」を参照してください。 ### ネットワークテストエラーのデバッグ ネットワークベースのテストの場合、IDT は、ホストマシン上の予約されていないポートに結合するエコーサーバーを起動します。WiFi またはセキュアソケットテストでタイムアウトまたは接続不可のためにエラーが発生した場合は、1024 〜 49151 の範囲の設定済みポートへのトラフィックを許可するようにネットワークが設定されていることを確認します。 セキュアソケットテストでは、デフォルトでポート 33333 および 33334 が使用されます。WiFi テストでは、デフォルトでポート 33335 が使用されます。これら 3 つのポートが使用中であるか、ファイアウォールまたはネットワークによってブロックされている場合は、userdata.json でテスト用に異なるポートを使用することを選択できます。詳細については、[ビルド、フラッシュ、テスト設定を設定する](cfg-dt-ud.md) を参照してください。以下のコマンドを使用して、特定のポートが使用中であるかどうかを確認できます。 + Windows: `netsh advfirewall firewall show rule name=all | grep port` + Linux: `sudo netstat -pan | grep port` + macOS: `netstat -nat | grep port` ### 同じバージョンのペイロードによる OTA 更新の失敗 OTA が実行された後にデバイス上に同じバージョンが存在するために OTA テストケースが失敗する場合、ビルドシステム (cmake など) が IDT の FreeRTOS ソースコード変更を認識せず、更新されたバイナリを構築していないことが原因である可能性があります。これにより、現在デバイス上にあるバイナリと同じバイナリで OTA が実行され、テストは失敗します。OTA 更新失敗のトラブルシューティングを行うには、まずサポートされている最新バージョンのビルドシステムを使用しているかを確認します。 ### `PresignedUrlExpired` テストケースの OTA テスト失敗 このテストの前提条件の 1 つは、OTA の更新時間が 60 秒を超えていることです。そうしないと、テストは失敗します。この問題が発生した場合、次のエラーメッセージがログに検出されます。「テストには 60 秒 (url の有効期限) 未満かかります。お気軽にご連絡ください。」 ### デバイスインターフェイスとポートのエラーのデバッグ このセクションでは、IDT がデバイスとの接続に使用するデバイスインターフェイスについて説明します。 #### サポートされているプラットフォーム IDT は、Linux、macOS、Windows をサポートしています。これら 3 つのプラットフォームは、アタッチされるシリアルデバイスに対して異なる命名スキームを設けています。 + Linux: `/dev/tty*` + macOS: `/dev/tty.*` または `/dev/cu.*` + Windows: COM\$1 デバイスポートを確認するには: + Linux/macOS の場合は、ターミナルを開き、`ls /dev/tty*` を実行します。 + macOS の場合は、ターミナルを開き、`ls /dev/tty.*` または `ls /dev/cu.*` を実行します。 + Windows の場合は、デバイスマネージャを開き、シリアルデバイスグループを展開します。 どのデバイスがポートに接続されているかを確認するには: + Linux の場合、`udev` パッケージがインストールされていることを確認してから、`udevadm info –name=PORT` を実行します。このユーティリティにより、正しいポートを使用していることを確認するのに役立つではデバイスドライバー情報が出力されます。 + macOS の場合、Launchpad を開いて **System Information** を検索します。 + Windows の場合は、デバイスマネージャを開き、シリアルデバイスグループを展開します。 #### デバイスインターフェイス 組み込みデバイスはそれぞれに異なり、シリアルポートを 1 つ持つものもあれば、複数持つものもあります。一般的に、マシンへの接続時に次の 2 つのポートがデバイスに割り当てられます。 + デバイスをフラッシュするためのデータポート。 + 出力を読み取る読み取りポート。 `device.json` ファイルで適切な読み取りポートを設定する必要があります。そのように設定しない場合は、デバイスからの出力の読み取りが失敗する可能性があります。 複数のポートがある場合、必ず `device.json` ファイルにあるデバイスの読み取りポートを使用してください。たとえば、Espressif WRover デバイスを接続し、デバイスに `/dev/ttyUSB0` と `/dev/ttyUSB1` の 2 つのポートが割り当てられている場合、`device.json` ファイルでは `/dev/ttyUSB1` を使用します。 Windows の場合は、同じロジックに従います。 #### デバイスデータの読み取り IDT for FreeRTOS は、個々のデバイスのビルドおよびフラッシュツールを使用してポート設定を指定します。デバイスをテストしていて、出力が取得できない場合は、次のようなデフォルト設定を試してみてください。 + ボーレート: 115200 + データビット: 8 + パリティ: なし + ストップビット: 1 + フロー制御: なし これらの設定は、IDT for FreeRTOS によって処理されます。それらを設定する必要はありません。ただし、同じ方法を使用して手動でデバイス出力を読み取ることができます。Linux または macOS では、`screen` コマンドを使用して行います。Windows では、TeraTerm などのプログラムを使用します。 `Screen: screen /dev/cu.usbserial 115200` `TeraTerm: Use the above-provided settings to set the fields explicitly in the GUI.` ### 開発ツールチェーンの問題 このセクションでは、ツールチェーンで生じる可能性のある問題を取り上げます。 #### Ubuntu での Code Composer Studio それより新しいバージョンの Ubuntu (17.10 と 18.04) だと、`glibc` パッケージのバージョンに Code Composer Studio 7.*x* バージョンとの互換性がありません。Code Composer Studio version 8.2 以降をインストールすることをお勧めします。 互換性がない場合、次のような症状が現れます。 + FreeRTOS がビルドやデバイスへのフラッシュに失敗する。 + Code Composer Studio インストーラがフリーズする。 + ビルドまたはフラッシュ中に、コンソールにログ出力が表示されない。 + ヘッドレスとして呼び出したビルドコマンドが GUI モードで起動しようとする。 ### ログ記録 IDT for FreeRTOS のログは 1 箇所に配置されます。ルート IDT ディレクトリから、`results/execution-id/` の以下のファイルにアクセスできます。 + `FRQ_Report.xml` + `awsiotdevicetester_report.xml` + `logs/test_group_id__test_case_id.log` `FRQ_Report.xml` と `logs/test_group_id__test_case_id.log` は、調査すべき最も重要なログです。`FRQ_Report.xml` には、特定のエラーメッセージで失敗したテストケースに関する情報が含まれています。次に、`logs/test_group_id__test_case_id.log` を使用して問題の詳細を確認し、状況を把握します。 #### コンソールエラー AWS IoT Device Tester を実行すると、障害は短いメッセージとともにコンソールに報告されます。`results/execution-id/logs/test_group_id__test_case_id.log` でエラーの詳細を確認します。 #### ログエラー 各テストスイートの実行には一意の実行 ID があり、これを使用して `results/execution-id` という名前のフォルダを作成します。テストケース別のログは `results/execution-id/logs` ディレクトリにあります。IDT for FreeRTOS コンソールの出力を使用して、失敗したテストケースの実行 ID、テストケース ID、およびテストグループ ID を検索します。次に、この情報を使用して、 という名前のテストケースのログファイルを検索して開きます`results/execution-id/logs/test_group_id__test_case_id.log`。このファイルの情報には、完全なビルドおよびフラッシュコマンド出力、テスト実行出力、およびより詳細な AWS IoT Device Tester コンソール出力が含まれます。 #### S3 バケットの問題 IDT の実行中に CTRL\$1C を押すと、クリーンアッププロセスが開始されます。このクリーンアップには、IDT テストの一部として作成された Amazon S3 リソースの削除が含まれます。クリーンアップを完了できない場合、Amazon S3 バケットが過剰に作成される問題が発生することがあります。つまり、次回 IDT を実行したときにテストが失敗し始めます。 IDT を停止するために CTRL\$1C を押す場合、この問題を回避するためにクリーンアッププロセスを完了させる必要があります。アカウントから手動で作成された Amazon S3 バケットを削除することもできます。 ## タイムアウトエラーのトラブルシューティング テストスイートの実行中にタイムアウトエラーが発生した場合は、タイムアウト乗数を指定してタイムアウトを増やします。この乗数は、デフォルトのタイムアウト値に適用されます。このフラグに設定された値はすべて、1.0 以上である必要があります。タイムアウトの乗数を使用するには、テストスイートの実行時に `--timeout-multiplier` フラグを使用します。 **Example** ``` ./devicetester_linux run-suite --suite-id FRQ_1.0.1 --pool-id DevicePool1 --timeout-multiplier 2.5 ``` ``` ./devicetester_linux run-suite --suite-id FRQ_1 --pool-id DevicePool1 --timeout-multiplier 2.5 ``` ## セルラー機能と AWS 料金 `device.JSON` ファイル`Yes`で`Cellular`この機能を に設定すると、FullSecureSockets はテストの実行に t.micro EC2 インスタンスを使用するため、 AWS アカウントに追加料金が発生する可能性があります。詳細については「[Amazon EC2 料金](https://aws.amazon.com/ec2/pricing/)」を参照してください。 ## 認定レポート生成ポリシー 資格レポートは、過去 2 年間にリリースされた FreeRTOS バージョンをサポートする AWS IoT Device Tester (IDT) バージョンによってのみ生成されます。サポートポリシーについてご質問がある場合は、 [AWS サポート](https://aws.amazon.com/contact-us/) までお問い合わせください。