エラーのトラブルシューティング - 無料RTOS

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

エラーのトラブルシューティング

各テストスイートの実行には一意の実行 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。このファイルの情報には以下が含まれます。

  • すべてのビルドおよびフラッシュコマンド出力。

  • テスト実行出力。

  • 無料RTOSコンソール出力IDTの詳細。

トラブルシューティングに次のワークフローをお勧めします。

  1. エラーが表示された場合「user/role は、このリソースへのアクセスを許可されていません「」。 で指定されているようにアクセス許可を設定してくださいAWS アカウントの作成と設定

  2. コンソール出力を読み、実行タスクUUIDや現在実行中のタスクなどの情報を見つけます。

  3. 各テストのエラーステートメントについて FRQ_Report.xml ファイルを確認します。このディレクトリには、各テストグループの実行ログが含まれています。

  4. /results/execution-id/logs にあるログファイルを確認します。

  5. 以下の問題領域のいずれかを調べてください。

    • /configs/ フォルダの設定ファイルなどのデバイスJSON設定。

    • デバイスインターフェイス。ログを確認して、どのインターフェイスが失敗しているかを判断します。

    • デバイスツール。デバイスをビルドおよびフラッシュするためのツールチェーンがインストールされ、正しく設定されていることを確認します。

    • FRQ 1.x.x では、無料RTOSソースコードのクリーンでクローンされたバージョンが利用可能であることを確認します。無料RTOSリリースは、無料RTOSバージョンに従ってタグ付けされます。そのコードの特定のバージョンのクローンを作成するには、次のコマンドを使用します。

      git clone --branch version-number https://github.com/aws/amazon-freertos.git cd amazon-freertos git submodule update --checkout --init --recursive

デバイス設定のトラブルシューティング

IDT for Free を使用する場合RTOS、バイナリを実行する前に正しい設定ファイルを取得する必要があります。解析エラーや設定エラーが発生する場合は、まず環境に適した設定テンプレートを見つけて使用してください。これらのテンプレートは、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 Free で によって生成されたエラーコードを示していますRTOS。

エラーコード エラーコード名 考えられる根本原因 トラブルシューティング

201

InvalidInputError

device.jsonconfig.json、または userdata.json のフィールドがないか、正しくない形式です。

必須フィールドが欠落していないこと、およびリストされたファイルで必須の形式であることを確認します。詳細については、マイクロコントローラーボードの最初のテスト を参照してください。

202

ValidationError

device.jsonconfig.json、または userdata.json のフィールドに無効な値が含まれています。

レポートのエラーコードの右側にあるエラーメッセージを確認します。

  • 無効な AWS リージョン - config.json ファイル内の有効な AWS リージョンを指定します。 AWS リージョンの詳細については、「リージョンとエンドポイント」を参照してください。

  • 無効な AWS 認証情報 - テストマシンに有効な AWS 認証情報を設定します (環境変数または認証情報ファイルを使用)。認証フィールドが正しく設定されていることを確認します。詳細については、AWS アカウントの作成と設定 を参照してください。

203

CopySourceCodeError

指定されたディレクトリに無料RTOSソースコードをコピーできません。

以下の項目について確認してください。

  • userdata.json ファイルで有効な sourcePath が指定されていることを確認してください。

  • 存在する場合は、無料RTOSソースコードディレクトリのbuildフォルダを削除します。詳細については、「ビルド、フラッシュ、テスト設定を設定する」を参照してください。

  • Windows では、ファイルパス名の文字数制限があります。ファイルパス名が長いと、エラーが発生します。

204

BuildSourceError

無料RTOSソースコードをコンパイルできません。

以下の項目について確認してください。

  • userdata.json ファイルの下にある buildTool 情報が正しいことを確認します。

  • cmake をビルドツールとして使用している場合は、buildTool コマンドで {{enableTests}} が指定されていることを確認します。詳細については、「ビルド、フラッシュ、テスト設定を設定する」を参照してください。

  • 例えば、スペースを含むシステム上のファイルパスに for FreeRTOS IDTを抽出した場合はC:\Users\My Name\Desktop\、パスが適切に解析されるようにビルドコマンド内に追加の引用符が必要になる場合があります。フラッシュコマンドにも同じことが必要な場合があります。

205

FlashOrRunTestError

IDT FreeRTOS は、 でフラッシュまたは無料RTOS実行できませんDUT。

userdata.json ファイルの下にある flashTool 情報が正しいことを確認します。詳細については、ビルド、フラッシュ、テスト設定を設定する を参照してください。

2.0.6

StartEchoServerError

IDT FreeRTOS は、 WiFi またはセキュアソケットテストのエコーサーバーを起動できません。

userdata.json ファイルの echoServerConfiguration で設定されたポートが使用中でないこと、ファイアウォールまたはネットワーク設定によってブロックされていないことを確認します。

デバッグ設定ファイルの解析エラー

JSON 設定の誤字により、解析エラーが発生することがあります。ほとんどの場合、問題はJSONファイルから括弧、カンマ、引用符を省略した結果です。IDT for FreeRTOS はJSON検証を実行し、デバッグ情報を出力します。エラーが発生した行、構文エラーの行番号と列番号が出力されます。この情報はエラーを修正するのに十分ですが、それでもエラーを見つけることができない場合は、、Atom や Sublime などのテキストエディタIDE、または などのオンラインツールを使用して、 で手動で検証を実行できますJSONLint。

デバッグテスト結果解析エラー

、Full _Core、Full _Onboard_ FreeRTOS-Libraries-Integration-Tests、Full _Onboard_、Full __、Full __、IDTまたは for FreeRTOS などの からテストグループを実行するとOTACore、シリアル接続を使用してテストデバイスからのテスト結果が解析されます。 FullTransportInterfaceTLSPKCS11PKCS11ECCPKCS11RSAPKCS11PreProvisionedECCPKCS11PreProvisionedRSA場合によっては、デバイス上の余分なシリアル出力がテスト結果の解析を妨げることがあります。

上記のケースでは、関係のないデバイス出力から派生した文字列など、テストケースの失敗に関する奇妙な理由が出力されます。IDT for FreeRTOS のテストケースログファイル (テスト中に受信した Free IDT RTOSのすべてのシリアル出力を含む) には、以下が表示される場合があります。

<unrelated device output> TEST(Full_PKCS11_Capabilities, PKCS11_Capabilities)<unrelated device output> <unrelated device output> PASS

上記の例では、無関係なデバイス出力はIDT、 for FreeRTOS が であるテスト結果を検出できないようにしますPASS

次の点を確認して、最適なテストを行ってください。

  • デバイスで使用されているロギングマクロがスレッドセーフであることを確認してください。詳細については、「Implementing the library logging macros」を参照してください。

  • テスト中は、シリアル接続への出力が最小限になるようにしてください。ロギングマクロが適切にスレッドセーフであっても、テスト結果はテスト中に別々の呼び出しで出力されるため、他のデバイス出力は問題になる可能性があります。

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 バージョンの無料RTOS版を使用している場合は、次の整合性チェックが適用されます。

F reeRTOSIntegrity テストグループを実行して失敗した場合は、まず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 ポートを認定するには、ファイルの「」セクションとexhaustiveminimal「」セクションに記載されているchecksums.jsonファイルが変更されていないことを確認してください。SDK を設定した状態で実行するには、minimal「」セクションの下にあるファイルが変更されていないことを確認します。

IDT で を実行し、freertosディレクトリ内の一部のファイルSDKを変更した場合は、 userdata ファイルSDKで を正しく設定してください。それ以外の場合、整合性チェッカーは freertos ディレクトリ内のすべてのファイルを検証します。

デバッグ FullWiFi テストグループの失敗

FRQ 1.x.x を使用していて、 FullWiFi テストグループで障害が発生し、AFQP_WiFiConnectMultipleAP「」テストが失敗した場合、両方のアクセスポイントが を実行しているホストコンピュータと同じサブネットにない可能性がありますIDT。両方のアクセスポイントが、 を実行しているホストコンピュータと同じサブネットにあることを確認しますIDT。

「必須パラメータ欠落」エラーのデバッグ

for IDT Free に新機能が追加されているためRTOS、設定ファイルに変更が加えられる可能性があります。古い設定ファイルを使用すると、設定が破損する可能性があります。このような場合は、results/execution-id/logs ディレクトリにある test_group_id__test_case_id.log ファイルに、すべての不足しているパラメータが明示的に一覧表示されます。IDT for FreeRTOS は、JSON設定ファイルスキーマを検証して、サポートされている最新バージョンが使用されていることを確認します。

デバッグ「テストを開始できませんでした」エラー

テストの開始中の障害を示唆するエラーが生じることがあります。原因はいくつか考えられるため、以下が正しいことを確認してください。

  • 実行コマンドに含めたプール名が実際に存在することを確認します。この名前は、device.json ファイルから直接参照されます。

  • プール内のデバイスの設定パラメータが正しいことを確認します。

デバッグ「テスト結果の開始を見つけることができない」エラー

テスト対象のデバイスによって出力された結果を解析IDTしようとすると、エラーが表示されることがあります。原因はいくつか考えられるため、以下の事項を確認して修正してください。

  • テスト対象のデバイスがホストマシンに安定して接続していることを確認します。これらのエラーを示すテストのログファイルをチェックして、受信IDTされているものを確認できます。

  • FRQ 1.x.x を使用していて、テスト対象のデバイスが低速ネットワークまたはその他のインターフェイスを介して接続されている場合、または無料RTOSテストグループログに「---------STARTINGTESTS---------」フラグと他の無料RTOSテストグループ出力が表示されない場合は、ユーザーデータ設定testStartDelaymsで の値を増やすことができます。詳細については、「ビルド、フラッシュ、テスト設定を設定する」を参照してください。

「テストの失敗:予期された __ の結果をデバッグしますが、」エラーが発生しました

テスト中に、テストの失敗を示すエラーが表示される場合があります。テストで一定数の結果が期待されているにもかかわらず、テスト中にその結果を確認できません。一部の無料RTOSテストは、 がデバイスからの出力IDTを確認する前に実行されます。このエラーが表示された場合は、userdata 設定の testStartDelayms 値を増やしてみてください。詳細については、「ビルド、フラッシュ、テスト設定を設定する」を参照してください。

ConditionalTests 「制約」エラーにより「________ のデバッグが選択されませんでした

これは、テストと互換性のないデバイスプールでテストを実行していることを意味します。これは E2E OTA テストで発生する可能性があります。 E2E 例えば、OTADataplaneMQTTテストグループとdevice.json設定ファイルの実行中に、OTANo または OTADataPlaneProtocolとして を選択しましたHTTP。実行するテストグループは、device.json で選択した機能と一致している必要があります。

デバイス出力モニタリング中のIDTタイムアウトのデバッグ

IDT は、さまざまな理由でタイムアウトする可能性があります。テストのデバイス出力モニタリングフェーズ中にタイムアウトが発生し、IDTテストケースログ内に結果が表示される場合は、結果が によって誤って解析されたことを意味しますIDT。その理由の 1 つとして、テスト結果の途中にインターリーブされたログメッセージが入っていることが考えられます。この場合、UNITYログの設定方法の詳細については、無料RTOS移植ガイドを参照してください。

デバイス出力モニタリング中にタイムアウトするもう 1 つの理由は、1 回のTLSテストケースの失敗後にデバイスが再起動することが考えられます。その後、デバイスはフラッシュされたイメージを実行し、これによって無限ループが発生します。これはログで確認できます。これが発生した場合は、テストに失敗した後にデバイスが再起動しないようにしてください。

「リソースへのアクセスが許可されていない」エラーをデバッグする

エラーが表示される場合があります」user/role は、ターミナル出力または の test_manager.log ファイルでこのリソースにアクセスする権限がありません/results/execution-id/logs。この問題を解決するには、AWS IoTDeviceTesterForFreeRTOSFullAccess 管理ポリシーをテストユーザーにアタッチします。詳細については、「AWS アカウントの作成と設定」を参照してください。

ネットワークテストエラーのデバッグ

ネットワークベースのテストの場合、 はホストマシン上の予約されていないポートに結合するエコーサーバーIDTを開始します。 WiFi または セキュアソケットテストでタイムアウトや使用できない接続が原因でエラーが発生した場合は、ネットワークが 1024 ~ 49151 の範囲の設定済みポートへのトラフィックを許可するように設定されていることを確認してください。

セキュアソケットテストでは、デフォルトでポート 33333 および 33334 が使用されます。デフォルトでは、 WiFi テストはポート 33335 を使用します。これら 3 つのポートが使用中であるか、ファイアウォールまたはネットワークによってブロックされている場合は、userdata.json でテスト用に異なるポートを使用することを選択できます。詳細については、ビルド、フラッシュ、テスト設定を設定する を参照してください。以下のコマンドを使用して、特定のポートが使用中であるかどうかを確認できます。

  • 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の無料RTOSソースコードへの変更に気づかず、更新されたバイナリを構築していない可能性があります。これによりOTA、 は現在デバイス上にあるのと同じバイナリで実行され、テストは失敗します。OTA 更新の失敗をトラブルシューティングするには、まず、サポートされている最新バージョンのビルドシステムを使用していることを確認します。

OTA テストケースでのPresignedUrlExpiredテスト失敗

このテストの前提条件の 1 つは、OTA更新時間が 60 秒以上であることです。そうしないとテストは失敗します。この問題が発生した場合、次のエラーメッセージがログに検出されます。「テストには 60 秒 (url の有効期限) 未満かかります。お気軽にご連絡ください。」

デバイスインターフェイスとポートエラーのデバッグ

このセクションでは、デバイスインターフェイスがデバイスへの接続IDTに使用するデバイスインターフェイスについて説明します。

サポートされているプラットフォーム

IDT は Linux、macOS 、および Windows をサポートしています。これら 3 つのプラットフォームは、アタッチされるシリアルデバイスに対して異なる命名スキームを設けています。

  • Linux: /dev/tty*

  • macOS: /dev/tty.* または /dev/cu.*

  • Windows: COM*

デバイスポートを確認するには:

  • 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デバイスをプラグインし、それに割り当てられた 2 つのポートが /dev/ttyUSB0と である場合は/dev/ttyUSB1device.json ファイル/dev/ttyUSB1で を使用します。

Windows の場合は、同じロジックに従います。

デバイスデータの読み取り

IDT for FreeRTOS は、個々のデバイスビルドとフラッシュツールを使用してポート設定を指定します。デバイスをテストしていて、出力が取得できない場合は、次のようなデフォルト設定を試してみてください。

  • ボーレート: 115200

  • データビット: 8

  • パリティ: なし

  • ストップビット: 1

  • フロー制御: なし

これらの設定はIDT、 for Free によって処理されますRTOS。それらを設定する必要はありません。ただし、同じ方法を使用して手動でデバイス出力を読み取ることができます。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 以降をインストールすることをお勧めします。

互換性がない場合、次のような症状が現れます。

  • デバイスRTOSへのビルドまたはフラッシュの失敗は無料です。

  • 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.xmllogs/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 バケットの問題

の実行CTRL+C中に を押すとIDT、 IDTはクリーンアッププロセスを開始します。そのクリーンアップの一部は、IDTテストの一部として作成された Amazon S3 リソースを削除することです。クリーンアップを完了できない場合、Amazon S3 バケットが過剰に作成される問題が発生することがあります。つまり、次回IDTテストを実行すると失敗し始めます。

CTRL+C を押して を停止する場合はIDT、この問題を回避するためにクリーンアッププロセスを完了させる必要があります。アカウントから手動で作成された Amazon S3 バケットを削除することもできます。

タイムアウトエラーのトラブルシューティング

テストスイートの実行中にタイムアウトエラーが発生した場合は、タイムアウト乗数を指定してタイムアウトを増やします。この乗数は、デフォルトのタイムアウト値に適用されます。このフラグに設定された値はすべて、1.0 以上である必要があります。タイムアウトの乗数を使用するには、テストスイートの実行時に --timeout-multiplier フラグを使用します。

IDT v3.0.0 and later
./devicetester_linux run-suite --suite-id FRQ_1.0.1 --pool-id DevicePool1 --timeout-multiplier 2.5
IDT v1.7.0 and earlier
./devicetester_linux run-suite --suite-id FRQ_1 --pool-id DevicePool1 --timeout-multiplier 2.5

セルラー機能と AWS 料金

ファイルYesCellular機能が に設定されている場合device.JSON、 FullSecureSockets はテストの実行に t.micro EC2インスタンスを使用します。これにより AWS 、アカウントに追加料金が発生する可能性があります。詳細については、「Amazon EC2の料金」を参照してください。

認定レポート生成ポリシー

認定レポートは、過去 2 年以内にリリースされた無料RTOSバージョンをサポートする AWS IoT Device Tester (IDT) バージョンによってのみ生成されます。サポートポリシーについてご質問がある場合は、 AWS Support までお問い合わせください。