翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
エラーのトラブルシューティング
各テストスイートの実行には一意の実行 ID があります。この ID を使用して、results
ディレクトリに results/
という名前のフォルダを作成します。テストグループ別のログは execution-id
results/
ディレクトリにあります。IDT for FreeRTOS コンソール出力を使用して、失敗したテストケースの実行 ID、テストケース ID、テストグループ ID を検索し、 という名前のテストケースのログファイルを開きますexecution-id
/logsresults/
。このファイルの情報には以下が含まれます。execution-id
/logs/test_group_id
__test_case_id
.log
-
すべてのビルドおよびフラッシュコマンド出力。
-
テスト実行出力。
-
無料RTOSコンソール出力IDTの詳細。
トラブルシューティングに次のワークフローをお勧めします。
-
エラーが表示された場合「
user/role
は、このリソースへのアクセスを許可されていません「」。 で指定されているようにアクセス許可を設定してくださいAWS アカウントの作成と設定。 -
コンソール出力を読み、実行タスクUUIDや現在実行中のタスクなどの情報を見つけます。
-
各テストのエラーステートメントについて
FRQ_Report.xml
ファイルを確認します。このディレクトリには、各テストグループの実行ログが含まれています。 -
/results/
にあるログファイルを確認します。execution-id
/logs -
以下の問題領域のいずれかを調べてください。
-
/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 |
|
必須フィールドが欠落していないこと、およびリストされたファイルで必須の形式であることを確認します。詳細については、マイクロコントローラーボードの最初のテスト を参照してください。 |
202 |
ValidationError |
|
レポートのエラーコードの右側にあるエラーメッセージを確認します。
|
203 |
CopySourceCodeError |
指定されたディレクトリに無料RTOSソースコードをコピーできません。 |
以下の項目について確認してください。
|
204 |
BuildSourceError |
無料RTOSソースコードをコンパイルできません。 |
以下の項目について確認してください。
|
205 |
FlashOrRunTestError |
IDT FreeRTOS は、 でフラッシュまたは無料RTOS実行できませんDUT。 |
|
2.0.6 |
StartEchoServerError |
IDT FreeRTOS は、 WiFi またはセキュアソケットテストのエコーサーバーを起動できません。 |
|
デバッグ設定ファイルの解析エラー
JSON 設定の誤字により、解析エラーが発生することがあります。ほとんどの場合、問題はJSONファイルから括弧、カンマ、引用符を省略した結果です。IDT for FreeRTOS はJSON検証を実行し、デバッグ情報を出力します。エラーが発生した行、構文エラーの行番号と列番号が出力されます。この情報はエラーを修正するのに十分ですが、それでもエラーを見つけることができない場合は、、Atom や Sublime などのテキストエディタIDE、または などのオンラインツールを使用して、 で手動で検証を実行できますJSONLint。
デバッグテスト結果解析エラー
、Full _Core、Full _Onboard_ FreeRTOS-Libraries-Integration-Tests
上記のケースでは、関係のないデバイス出力から派生した文字列など、テストケースの失敗に関する奇妙な理由が出力されます。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 テストグループを実行して失敗した場合は、まず
ディレクトリファイルを変更していないことを確認してください。変更しておらず、問題が解消しない場合は、正しいブランチを使用していることを確認してください。IDTのfreertos
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 ポートを認定するには、ファイルの「」セクションとexhaustive
minimal
「」セクションに記載されているchecksums.json
ファイルが変更されていないことを確認してください。SDK を設定した状態で実行するには、minimal
「」セクションの下にあるファイルが変更されていないことを確認します。
IDT で を実行し、
ディレクトリ内の一部のファイルSDKを変更した場合は、 freertos
userdata
ファイルSDKで を正しく設定してください。それ以外の場合、整合性チェッカーは
ディレクトリ内のすべてのファイルを検証します。freertos
デバッグ FullWiFi テストグループの失敗
FRQ 1.x.x を使用していて、 FullWiFi テストグループで障害が発生し、AFQP_WiFiConnectMultipleAP
「」テストが失敗した場合、両方のアクセスポイントが を実行しているホストコンピュータと同じサブネットにない可能性がありますIDT。両方のアクセスポイントが、 を実行しているホストコンピュータと同じサブネットにあることを確認しますIDT。
「必須パラメータ欠落」エラーのデバッグ
for IDT Free に新機能が追加されているためRTOS、設定ファイルに変更が加えられる可能性があります。古い設定ファイルを使用すると、設定が破損する可能性があります。このような場合は、results/
ディレクトリにある execution-id
/logs
ファイルに、すべての不足しているパラメータが明示的に一覧表示されます。IDT for FreeRTOS は、JSON設定ファイルスキーマを検証して、サポートされている最新バージョンが使用されていることを確認します。test_group_id
__test_case_id
.log
デバッグ「テストを開始できませんでした」エラー
テストの開始中の障害を示唆するエラーが生じることがあります。原因はいくつか考えられるため、以下が正しいことを確認してください。
-
実行コマンドに含めたプール名が実際に存在することを確認します。この名前は、
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
/logsAWS 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/ttyUSB1
、device.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.xml
と logs/
は、調査すべき最も重要なログです。test_group_id
__test_case_id
.logFRQ_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/
ディレクトリにあります。IDT for FreeRTOS コンソールの出力を使用して、失敗したテストケースの実行 ID、テストケース ID、テストグループ ID を見つけます。次に、この情報を使用して、 という名前のテストケースのログファイルを検索して開きますexecution-id
/logsresults/
。このファイルの情報には、完全なビルドコマンドとフラッシュコマンドの出力、テスト実行の出力、およびより詳細な AWS IoT Device Tester コンソールの出力が含まれます。execution-id
/logs/test_group_id
__test_case_id
.log
S3 バケットの問題
の実行CTRL+C中に を押すとIDT、 IDTはクリーンアッププロセスを開始します。そのクリーンアップの一部は、IDTテストの一部として作成された Amazon S3 リソースを削除することです。クリーンアップを完了できない場合、Amazon S3 バケットが過剰に作成される問題が発生することがあります。つまり、次回IDTテストを実行すると失敗し始めます。
CTRL+C を押して を停止する場合はIDT、この問題を回避するためにクリーンアッププロセスを完了させる必要があります。アカウントから手動で作成された Amazon S3 バケットを削除することもできます。
タイムアウトエラーのトラブルシューティング
テストスイートの実行中にタイムアウトエラーが発生した場合は、タイムアウト乗数を指定してタイムアウトを増やします。この乗数は、デフォルトのタイムアウト値に適用されます。このフラグに設定された値はすべて、1.0 以上である必要があります。タイムアウトの乗数を使用するには、テストスイートの実行時に --timeout-multiplier
フラグを使用します。
セルラー機能と AWS 料金
ファイルYes
で Cellular
機能が に設定されている場合device.JSON
、 FullSecureSockets はテストの実行に t.micro EC2インスタンスを使用します。これにより AWS 、アカウントに追加料金が発生する可能性があります。詳細については、「Amazon EC2の料金
認定レポート生成ポリシー
認定レポートは、過去 2 年以内にリリースされた無料RTOSバージョンをサポートする AWS IoT Device Tester (IDT) バージョンによってのみ生成されます。サポートポリシーについてご質問がある場合は、 AWS Support