Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Fehlerbehebung

Jede Ausführung einer Testsuite verfügt über eine eindeutige Ausführungs-ID, die verwendet wird, um im Verzeichnis results einen Ordner mit dem Namen results/execution-id zu erstellen. Die einzelnen Testgruppenprotokolle befinden sich im Verzeichnis results/execution-id/logs. Verwenden Sie die IDT for FreeRTOS-Konsolenausgabe, um die Ausführungs-ID, Testfall-ID und Testgruppen-ID des fehlgeschlagenen Testfalls zu ermitteln, und öffnen Sie dann die Protokolldatei für diesen Testfall mit dem Namen. results/execution-id/logs/test_group_id__test_case_id.log Die Informationen in dieser Datei beinhalten Folgendes:

Wir empfehlen folgenden Workflow für die Fehlersuche:

Fehlerbehebung bei der Gerätekonfiguration

Wenn Sie IDT für FreeRTOS verwenden, müssen Sie die richtigen Konfigurationsdateien einrichten, bevor Sie die Binärdatei ausführen. Wenn Sie Parsing- und Konfigurationsfehler erhalten, sollten Sie als Erstes eine für Ihre Umgebung geeignete Konfigurationsvorlage suchen und anwenden. Diese Vorlagen befinden sich im Verzeichnis IDT_ROOT/configs.

Wenn weiterhin Probleme auftreten, beachten Sie den folgenden Debugging-Vorgang.

Wo suche ich?

Lesen Sie zunächst die Konsolenausgabe, um Informationen zu finden, z. B. die Ausführungs-UUID, die in dieser Dokumentation als execution-id bezeichnet wird.

Suchen Sie als Nächstes in der Datei FRQ_Report.xml im Verzeichnis /results/execution-id. Diese Datei enthält alle ausgeführten Testfälle und Fehlerausschnitte zu jedem Fehler. Suchen Sie zum Abrufen aller Ausführungsprotokolle für jeden Testfall jeweils nach der Datei /results/execution-id/logs/test_group_id__test_case_id.log.

IDT-Fehlercodes

In der folgenden Tabelle werden die von IDT für FreeRTOS generierten Fehlercodes erklärt:

Debuggen von Parsing-Fehlern

Es kann vorkommen, dass ein Tippfehler in einer JSON-Konfiguration zu Parsing-Fehlern führt. In den meisten Fällen ist die Ursache des Problems eine fehlende Klammer oder ein fehlendes Komma oder Anführungszeichen in Ihrer JSON-Datei. IDT for FreeRTOS führt eine JSON-Validierung durch und druckt Debugging-Informationen. Gedruckt werden die Zeile, in der der Fehler aufgetreten ist, sowie Zeilennummer und Spaltennummer des Syntaxfehlers. Diese Informationen sollten ausreichen, um Ihnen bei der Behebung des Fehlers zu helfen. Wenn Sie jedoch immer noch Probleme haben, den Fehler zu finden, können Sie die Validierung manuell in Ihrer IDE, einem Texteditor wie Atom oder Sublime oder über ein Online-Tool wie durchführen. JSONLint

Fehler bei der Integritätsprüfung debuggen

Wenn Sie die RTOSIntegrity Testgruppe Free ausführen und Fehler auftreten, stellen Sie zunächst sicher, dass Sie keine der freertos Verzeichnisdateien geändert haben. Falls dies nicht der Fall ist und weiterhin Probleme auftreten, stellen Sie sicher, dass Sie den richtigen Zweig verwenden. Wenn Sie den list-supported-products Befehl IDT ausführen, können Sie herausfinden, welchen markierten Zweig des freertos Repositorys Sie verwenden sollten.

Wenn Sie den richtigen markierten Zweig des freertos Repositorys geklont haben und immer noch Probleme haben, stellen Sie sicher, dass Sie den Befehl auch ausgeführt haben. submodule update Der Klon-Workflow für das freertos Repo sieht wie folgt aus.

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

Die Liste der Dateien, nach denen die Integritätsprüfung sucht, befindet sich in der checksums.json Datei in Ihrem freertos Verzeichnis. Um einen FreeRTOS-Port ohne Änderungen an den Dateien und der Ordnerstruktur zu qualifizieren, stellen Sie sicher, dass keine der in den Abschnitten '' und exhaustive 'minimal' der checksums.json Datei aufgelisteten Dateien geändert wurde. Um die Ausführung mit einem konfigurierten SDK durchzuführen, stellen Sie sicher, dass keine der Dateien im Abschnitt minimal '' geändert wurde.

Wenn Sie IDT mit einem SDK ausführen und einige Dateien in Ihrem freertos Verzeichnis geändert haben, stellen Sie sicher, dass Sie Ihr SDK in Ihrer userdata Datei korrekt konfigurieren. Andernfalls überprüft der Integritätsprüfer alle Dateien im freertos Verzeichnis.

Fehler bei FullWiFi Testgruppen debuggen

Wenn Sie Fehler in der FullWiFi Testgruppe feststellen und der "AFQP_WiFiConnectMultipleAP" Test fehlschlägt, kann dies daran liegen, dass sich beide Access Points nicht im selben Subnetz befinden wie der Host-Computer, auf dem IDT ausgeführt wird. Stellen Sie sicher, dass sich beide Access Points im selben Subnetz befinden wie der Hostcomputer, auf dem IDT ausgeführt wird.

Debuggen von Fehlern aufgrund fehlender erforderlicher Parameter

Da IDT for FreeRTOS um neue Funktionen erweitert wird, können Änderungen an den Konfigurationsdateien vorgenommen werden. Bei Verwendung einer alten Konfigurationsdatei kann Ihre Konfiguration beschädigt werden. In diesem Fall listet die Datei test_group_id__test_case_id.log im Verzeichnis results/execution-id/logs explizit alle fehlenden Parameter auf. IDT for FreeRTOS validiert Ihre JSON-Konfigurationsdateischemas, um sicherzustellen, dass die neueste unterstützte Version verwendet wurde.

Debuggen von Fehlern aufgrund fehlgeschlagenen Teststarts

Möglicherweise finden Sie Hinweise auf Fehler beim Teststart. Da es mehrere mögliche Ursachen gibt, überprüfen Sie die folgenden Bereiche auf ihre Richtigkeit:

Debuggen von Fehlern aufgrund fehlender Autorisierung zum Zugriff auf eine Ressource

Möglicherweise wird in der Terminalausgabe oder in der Datei darunter der Fehler "user/roleist nicht autorisiert, auf diese Ressource zuzugreifen“ angezeigt. test_manager.log /results/execution-id/logs Um dieses Problem zu beheben, fügen Sie die AWSIoTDeviceTesterForFreeRTOSFullAccess-verwaltete Richtlinie an Ihren Testbenutzer an. Weitere Informationen finden Sie unter .

Debuggen von Fehlern beim Netzwerktest

Für netzwerkbasierte Tests startet IDT einen Echo-Server, der sich an einen nicht reservierten Port auf dem Hostcomputer bindet. Wenn bei den Tests oder Secure Sockets aufgrund von Zeitüberschreitungen oder nicht verfügbaren Verbindungen Fehler auftreten, stellen Sie sicher, dass Ihr Netzwerk so konfiguriert ist, dass Datenverkehr zu konfigurierten Ports im Bereich 1024 bis 49151 zugelassen wird. WiFi

Der Secure Sockets-Test verwendet standardmäßig die Ports 33333 und 33334. Die WiFi Tests verwenden standardmäßig Port 33335. Wenn diese drei Ports von einer Firewall oder einem Netzwerk verwendet oder blockiert werden, können Sie verschiedene Ports in userdata.json zum Testen verwenden. Weitere Informationen finden Sie unter Konfiguration von Build-, Flash- und Testeinstellungen. Sie können mit den folgenden Befehle überprüfen, ob ein bestimmter Port verwendet wird:

OTA-Updatefehler aufgrund derselben Version der Nutzlast

Wenn OTA-Testfälle fehlschlagen, weil sich dieselbe Version auf dem Gerät befindet, nachdem ein OTA ausgeführt wurde, kann dies daran liegen, dass Ihr Build-System (z. B. cmake) die Änderungen von IDT am FreeRTOS-Quellcode nicht bemerkt und keine aktualisierte Binärdatei erstellt. Dies führt dazu, dass OTA mit der gleichen Binärdatei durchgeführt wird, die sich bereits auf dem Gerät befindet, weshalb der Test fehlschlägt. Um OTA-Updatefehler zu beheben, stellen Sie zunächst sicher, dass Sie die neueste unterstützte Version Ihres Build-Systems verwenden.

OTA-Testfehler im PresignedUrlExpired-Testfall

Eine Voraussetzung für diesen Test ist, dass die OTA-Update-Zeit mehr als 60 Sekunden betragen sollte, da der Test andernfalls fehlschlagen würde. In diesem Fall ist im Protokoll die folgende Fehlermeldung zu finden: „Test takes less than 60 seconds (url expired time) to finish. (Abschluss des Tests dauert weniger als 60 Sekunden (URL-Ablaufzeit). Please reach out to us (Bitte kontaktieren Sie uns).“

Debuggen von Schnittstellen- und Portfehlern des Geräts

Dieser Abschnitt enthält Informationen über die Geräteschnittstellen, die IDT zur Verbindung mit Ihren Geräten verwendet.

Unterstützte Plattformen

IDT unterstützt Linux, MacOS und Windows. Auf allen drei Plattformen werden unterschiedliche Benennungen für serielle Geräte verwendet, die mit ihnen verbunden sind:

So überprüfen Sie den Geräteport:

Um zu überprüfen, welches Gerät mit einem Port verbunden ist:

Geräteschnittstellen

Jedes eingebettete Gerät ist anders. Dies bedeutet, dass sie einen oder mehrere serielle Ports haben können. Es ist üblich, dass Geräte über zwei Ports verfügen, wenn sie mit einer Maschine verbunden sind:

Lesen von Gerätedaten

IDT for FreeRTOS verwendet individuelle Gerätebau- und Flash-Tools, um die Portkonfiguration zu spezifizieren. Wenn Sie Ihr Gerät testen und keine Ausgabe erhalten, versuchen Sie es mit den folgenden Standardeinstellungen:

Diese Einstellungen werden von IDT für FreeRTOS verwaltet. Sie müssen sie nicht festlegen. Sie können jedoch dieselbe Methode verwenden, um die Geräteausgabe manuell zu lesen. Unter Linux oder macOS ist dies mit dem Befehl screen möglich. Unter Windows können Sie ein Programm wie verwenden. TeraTerm

Screen: screen /dev/cu.usbserial 115200

TeraTerm: Use the above-provided settings to set the fields explicitly in the GUI.

Probleme mit der Entwicklungs-Toolchain

In diesem Abschnitt werden Probleme beschrieben, die mit Ihrer Tool-Chain auftreten können.

Code Composer Studio auf Ubuntu

In den neueren Versionen von Ubuntu (17.10 und 18.04) ist eine Version des glibc-Pakets enthalten, die nicht mit den Versionen von Code Composer Studio 7.x kompatibel ist. Wir empfehlen, Code Composer Studio Version 8.2 oder höher zu installieren.

Folgende Anzeichen der Inkompatibilität könnten auftreten:

Protokollierung

IDT for FreeRTOS-Protokolle werden an einem einzigen Ort gespeichert. Im IDT-Stammverzeichnis sind diese Dateien unter results/execution-id/ verfügbar:

FRQ_Report.xml und logs/test_group_id__test_case_id.log sind die wichtigsten Protokolle, die Sie untersuchen sollten. FRQ_Report.xml enthält Informationen dazu, für welche Testfälle Fehler mit einer bestimmten Fehlermeldung aufgetreten sind. Anschließend können Sie logs/test_group_id__test_case_id.log verwenden, um das Problem genauer zu analysieren und so einen besseren Kontext zu erhalten.

Konsolenfehler

Wenn AWS IoT Device Tester es ausgeführt wird, werden Fehler mit kurzen Meldungen an die Konsole gemeldet. Weitere Informationen zum Fehler finden Sie unter results/execution-id/logs/test_group_id__test_case_id.log.

Protokollfehler

Jede Ausführung der Testsuite verfügt über eine eindeutige Ausführungs-ID, die zum Erstellen eines Ordners mit dem Namen results/execution-id verwendet wird. Einzelne Testfallprotokolle befinden sich im Verzeichnis results/execution-id/logs. Verwenden Sie die Ausgabe der IDT for FreeRTOS-Konsole, um die Ausführungs-ID, die Testfall-ID und die Testgruppen-ID des fehlgeschlagenen Testfalls zu ermitteln. Verwenden Sie dann diese Informationen, um die Protokolldatei für diesen Testfall mit dem Namen zu finden und zu öffnen. results/execution-id/logs/test_group_id__test_case_id.log Die Informationen in dieser Datei umfassen die vollständige Build- und Flash-Befehlsausgabe, die Ausgabe der Testausführung und eine AWS IoT Device Tester ausführlichere Konsolenausgabe.

Probleme mit dem S3-Bucket

Wenn Sie CTRL+C während der Ausführung von IDT drücken, startet IDT einen Bereinigungsprozess. Ein Teil dieser Bereinigung besteht darin, Amazon S3 S3-Ressourcen zu entfernen, die im Rahmen der IDT-Tests erstellt wurden. Wenn die Bereinigung nicht abgeschlossen werden kann, tritt möglicherweise ein Problem auf, bei dem zu viele Amazon S3 S3-Buckets erstellt wurden. Das bedeutet, dass die Tests fehlschlagen werden, wenn Sie IDT das nächste Mal ausführen.

Wenn Sie CTRL+C die Taste drücken, um IDT zu beenden, müssen Sie den Bereinigungsvorgang beenden lassen, um dieses Problem zu vermeiden. Sie können auch die manuell erstellten Amazon S3 S3-Buckets aus Ihrem Konto löschen.

Fehlerbehebung bei Timeout-Fehlern

Wenn beim Ausführen einer Testsuite Timeout-Fehler auftreten, erhöhen Sie das Timeout, indem Sie einen Timeout-Multiplikatorfaktor angeben. Dieser Faktor wird auf den Standardwert für die Zeitüberschreitung angewendet. Jeder Wert für dieses Kennzeichen muss größer als oder gleich 1,0 sein. Um den Timeout-Multiplikator zu verwenden, verwenden Sie beim Ausführen der Testsuite das Flag --timeout-multiplier.

Mobilfunkfunktion und Gebühren AWS

Wenn die Cellular Funktion Yes in Ihrer device.JSON Datei auf eingestellt ist, FullSecureSockets werden EC2 T.micro-Instances für die Durchführung von Tests verwendet, was zu zusätzlichen Kosten für Ihr AWS Konto führen kann. Weitere Informationen finden Sie unter EC2 Amazon-Preise.

Richtlinie zur Erstellung von Qualifikationsberichten

Qualifizierungsberichte werden nur von AWS IoT Device Tester (IDT-) Versionen generiert, die FreeRTOS-Versionen unterstützen, die in den letzten zwei Jahren veröffentlicht wurden. Wenn Sie Fragen zu den Support-Richtlinien haben, wenden Sie sich bitte an. AWS -Support