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, die Testfall-ID und die Testgruppen-ID des fehlgeschlagenen Testfalls zu finden, und öffnen Sie dann die Protokolldatei für diesen Testfall mit dem Namenresults/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 erläutert:

Fehler beim Parsen von Konfigurationsdateien beim Debuggen

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 gibt Debugging-Informationen aus. Gedruckt werden die Zeile, in der der Fehler aufgetreten ist, sowie Zeilennummer und Spaltennummer des Syntaxfehlers. Diese Informationen sollten für die Fehlerbehebung ausreichen. Sollten weiterhin Probleme auftreten, können Sie eine Validierung manuell in Ihrer IDE, in einem Text-Editor wie Atom oder Sublime oder über ein Online-Tool wie JSONLint durchführen.

Fehler beim Analysieren von Testergebnissen beim Debuggen

Beim Ausführen einer Testgruppe vonKostenlose RTOS-Bibliotheken-Integrationstests, wieFullTransportInterfaceTLS, FullPKCS11_Core, FullPKCS11_Onboard_ECC, FullPKCS11_Onboard_RSA, FullPKCS11_PreProvisioned_ECC, vollständige PKCS11_PreProvisioned_RSA, oderOTA-Core, IDT for FreeRTOS analysiert die Testergebnisse des Testgeräts mit der seriellen Verbindung. Manchmal können zusätzliche serielle Ausgänge am Gerät die Analyse der Testergebnisse beeinträchtigen.

Im oben genannten Fall werden seltsame Testfall-Fehlerursachen wie Zeichenketten ausgegeben, die von Geräteausgängen stammen, die nichts miteinander zu tun haben. Die Testfallprotokolldatei von IDT for FreeRTOS (die alle seriellen Ausgaben enthält, die IDT for FreeRTOS während des Tests erhalten hat) kann Folgendes anzeigen:

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

Im obigen Beispiel verhindert die unabhängige Geräteausgabe, dass IDT for FreeRTOS das Testergebnis erkennt, dasPASS.

Überprüfen Sie die folgenden Punkte, um optimale Tests zu gewährleisten.

Ein IDT for FreeRTOS Testfallprotokoll würde idealerweise eine ununterbrochene Ausgabe der Testergebnisse wie folgt anzeigen:

---------STARTING TESTS---------
TEST(Full_OTA_PAL, otaPal_CloseFile_ValidSignature) PASS
TEST(Full_OTA_PAL, otaPal_CloseFile_InvalidSignatureBlockWritten) PASS
-----------------------
2 Tests 0 Failures 0 Ignored        
      

Fehler bei der Integritätsprüfung beim Debuggen

Wenn Sie die FRQ 1.x.x-Version von FreeRTOS verwenden, gelten die folgenden Integritätsprüfungen.

Wenn Sie die FreeRTOSIntegrity-Testgruppe ausführen und Fehler auftreten, stellen Sie zunächst sicher, dass Sie keine derfreertosVerzeichnisdateien. Wenn Sie keine Probleme haben und immer noch Probleme haben, stellen Sie sicher, dass Sie den richtigen Zweig verwenden. Wenn Sie IDTs ausführenlist-supported-productsBefehl, Sie können herausfinden, welcher markierte Zweig desfreertosRepo, das Sie verwenden sollten.

Wenn Sie den richtigen markierten Zweig des geklont habenfreertosRepo und immer noch Probleme, stellen Sie sicher, dass Sie auch das ausgeführt habensubmodule updateBefehl. Der Klon-Workflow für denfreertosRepo lautet wie folgt.

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 der Integritätsprüfer sucht, befindet sich in derchecksums.jsonDatei in IhremfreertosVerzeichnis. Um einen FreeRTOS-Port ohne Änderungen an Dateien und der Ordnerstruktur zu qualifizieren, stellen Sie sicher, dass keine der in 'aufgeführten Dateienexhaustive'und'minimal'Abschnitte derchecksums.jsonDie Datei wurde geändert. Um mit einem konfigurierten SDK zu starten, stellen Sie sicher, dass keine der Dateien unter dem 'minimal'Abschnitt wurde geändert.

Wenn Sie IDT mit einem SDK ausführen und einige Dateien in IhremfreertosVerzeichnis, stellen Sie dann sicher, dass Sie Ihr SDK in Ihrem korrekt konfigurierenuserdataDatei. Andernfalls überprüft der Integrity Checker alle Dateien in derfreertosVerzeichnis.

DebuggenFullWiFiFehler in der Testgruppe

Wenn Sie FRQ 1.x.x verwenden und Fehler in derFullWiFiTestgruppe und die“AFQP_WiFiConnectMultipleAP„Der Test schlägt fehl. Dies könnte daran liegen, dass sich beide Access Points nicht im selben Subnetz wie der Hostcomputer befinden, auf dem IDT ausgeführt wird. Stellen Sie sicher, dass sich beide Access Points im selben Subnetz wie der Hostcomputer befinden, auf dem IDT ausgeführt wird.

Debuggen von Fehlern aufgrund fehlender erforderlicher Parameter

Da IDT für 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 eines Fehlers „Test konnte nicht gestartet werden“

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 eines Fehlers „Der Start der Testergebnisse konnte nicht gefunden werden“

Möglicherweise treten Fehler auf, wenn IDT versucht, die vom zu testenden Gerät ausgegebenen Ergebnisse zu analysieren. Es gibt mehrere mögliche Ursachen. Überprüfen Sie daher die folgenden Bereiche auf Richtigkeit:

Debuggen des Fehlers „Testfehler: erwartete __ Ergebnisse, aber ___“

Möglicherweise werden beim Testen Fehler angezeigt, die auf einen Testfehler hinweisen. Der Test erwartet eine bestimmte Anzahl von Ergebnissen und sieht diese während des Tests nicht. Einige FreeRTOS-Tests werden ausgeführt, bevor IDT die Ausgabe des Geräts sieht. Wenn Sie diesen Fehler sehen, können Sie versuchen, den Wert von zu erhöhentestStartDelaymsin deinemBenutzerdatenKonfiguration. Weitere Informationen finden Sie unter Konfiguration von Build-, Flash- und Testeinstellungen.

Das Debuggen eines „________“ wurde aus folgenden Gründen nicht ausgewähltConditionalTestsFehler „Einschränkungen“

Dies bedeutet, dass Sie einen Test in einem Gerätepool ausführen, der mit dem Test nicht kompatibel ist. Dies kann bei den OTA E2E-Tests passieren. Zum Beispiel beim Laufen desOTADataplaneMQTTTestgruppe und in Ihremdevice.jsonKonfigurationsdatei, Sie haben OTA ausgewählt alsNeinoderOTADataPlaneProtocolalsHTTP. Die für den Lauf ausgewählte Testgruppe muss mit Ihrer übereinstimmendevice.jsonAuswahl von Fähigkeiten.

Debuggen eines IDT-Timeouts während der Überwachung der Geräteausgabe

IDT kann aus einer Reihe von Gründen zu einem Timeout führen. Wenn während der Phase der Überwachung der Geräteausgänge eines Tests ein Timeout auftritt und Sie die Ergebnisse im IDT-Testfallprotokoll sehen können, bedeutet dies, dass die Ergebnisse von IDT falsch analysiert wurden. Ein Grund könnten die verschachtelten Logmeldungen in der Mitte der Testergebnisse sein. Wenn dies der Fall ist, lesen Sie bitte in derAnleitung zur kostenlosen RTOS-Portierungfür weitere Informationen darüber, wie die UNITY-Logs eingerichtet werden sollten.

Ein weiterer Grund für ein Timeout bei der Überwachung der Geräteausgabe könnte ein Neustart des Geräts nach einem einzigen TLS-Testfall sein. Das Gerät führt dann das blinkende Bild aus und löst eine Endlosschleife aus, die in den Protokollen zu sehen ist. Stellen Sie in diesem Fall sicher, dass Ihr Gerät nach einem Testfehler nicht neu gestartet wird.

Debuggen von Fehlern aufgrund fehlender Autorisierung zum Zugriff auf eine Ressource

Möglicherweise wird der Fehler „Benutzer/Rolle ist nicht berechtigt, auf diese Ressource zuzugreifen“ in der Terminalausgabe oder in der Datei test_manager.log unter /results/execution-id/logs angezeigt. Um dieses Problem zu beheben, fügen Sie die AWSIoTDeviceTesterForFreeRTOSFullAccess-verwaltete Richtlinie an Ihren Testbenutzer an. Weitere Informationen finden Sie unter Erstellen und konfigurieren Sie ein Konto AWS.

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 Sie aufgrund von Timeouts oder nicht verfügbaren Verbindungen in derWiFioder Secure-Socket-Tests: Stellen Sie sicher, dass Ihr Netzwerk so konfiguriert ist, dass Datenverkehr zu konfigurierten Ports im Bereich 1024 — 49151 zugelassen wird.

Der Secure Sockets-Test verwendet standardmäßig die Ports 33333 und 33334. DerWiFitests verwendet 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 dieselbe Version auf dem Gerät war, nachdem ein OTA ausgeführt wurde, kann es 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 for FreeRTOS übernommen. 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 verwenden wieTeraTerm.

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 Logs 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

WannAWS IoT Device Testerausgefü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 finden. Verwenden Sie dann diese Informationen, um die Protokolldatei für den Testfall mit dem Namen zu finden und zu öffnenresults/execution-id/logs/test_group_id__test_case_id.logDie Informationen in dieser Datei beinhalten die vollständige Build- und Flash-Befehlsausgabe, die Ausgabe der Testausführung und weitere ausführliche InformationenAWS IoT Device TesterKonsolenausgang.

Probleme mit S3-Buckets

Wenn du drückstCTRL+Cwährend IDT ausgeführt wird, startet IDT einen Bereinigungsprozess. Ein Teil dieser Bereinigung besteht darin, Amazon S3-Ressourcen zu entfernen, die im Rahmen der IDT-Tests erstellt wurden. Wenn die Bereinigung nicht abgeschlossen werden kann, kann es sein, dass Sie auf ein Problem stoßen, bei dem zu viele Amazon S3-Buckets erstellt wurden. Dies bedeutet, dass die Tests beim nächsten Mal, wenn Sie IDT ausführen, fehlschlagen werden.

Wenn du drückstCTRL+CUm IDT zu stoppen, müssen Sie den Bereinigungsprozess abschließen lassen, um dieses Problem zu vermeiden. Sie können auch die Amazon S3-Buckets aus Ihrem Konto löschen, die manuell erstellt wurden.

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 undAWSGebühren

Wenn derCellularFunktion ist eingestellt aufYesin deinemdevice.JSONdatei,FullSecureSocketsverwendet t.micro EC2-Instances für die Ausführung von Tests. Dies kann zusätzliche Kosten für Sie verursachenAWSKonto. Weitere Informationen dazu finden Sie unter Amazon EC2 – Preise.

Richtlinie zur Erstellung von Qualifikationsberichten

Qualifikationsberichte werden nur generiert vonAWS IoT Device Tester(IDT) -Versionen, 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 anAWS Support.