Wählen Sie Ihre Cookie-Einstellungen aus

Wir verwenden essentielle Cookies und ähnliche Tools, die für die Bereitstellung unserer Website und Services erforderlich sind. Wir verwenden Performance-Cookies, um anonyme Statistiken zu sammeln, damit wir verstehen können, wie Kunden unsere Website nutzen, und Verbesserungen vornehmen können. Essentielle Cookies können nicht deaktiviert werden, aber Sie können auf „Anpassen“ oder „Ablehnen“ klicken, um Performance-Cookies abzulehnen.

Wenn Sie damit einverstanden sind, verwenden AWS und zugelassene Drittanbieter auch Cookies, um nützliche Features der Website bereitzustellen, Ihre Präferenzen zu speichern und relevante Inhalte, einschließlich relevanter Werbung, anzuzeigen. Um alle nicht notwendigen Cookies zu akzeptieren oder abzulehnen, klicken Sie auf „Akzeptieren“ oder „Ablehnen“. Um detailliertere Entscheidungen zu treffen, klicken Sie auf „Anpassen“.

Beheben von Fehlern in der  - Kostenlos RTOS

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.

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.

Beheben von Fehlern in der 

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 RTOS For-Free-Konsolenausgabe, um die Ausführungs-ID, die Testfall-ID und die Testgruppen-ID des fehlgeschlagenen Testfalls zu ermitteln, und öffnen Sie dann die Protokolldatei für den Testfall mit dem Namen. results/execution-id/logs/test_group_id__test_case_id.log Die Informationen in dieser Datei beinhalten Folgendes:

  • Vollständige Build- und Flash-Befehlsausgabe.

  • Testausführungsausgabe.

  • Ausführlicher IDT für die kostenlose RTOS Konsolenausgabe.

Wir empfehlen folgenden Workflow für die Fehlersuche:

  1. Wenn Sie den Fehler sehen“user/role ist nicht berechtigt, auf diese Ressource zuzugreifen“, stellen Sie sicher, dass Sie die unter angegebenen Berechtigungen konfigurierenErstellen und konfigurieren Sie ein AWS Konto.

  2. Lesen Sie die Konsolenausgabe, um Informationen zu finden, z. B. zur Ausführung UUID und zur aktuellen Ausführung von Aufgaben.

  3. Suchen Sie in der Datei FRQ_Report.xml nach Fehleranweisungen für jeden Test. Dieses Verzeichnis enthält Ausführungsprotokolle für jede Testgruppe.

  4. Schauen Sie in den Protokolldateien unter nach/results/execution-id/logs.

  5. Untersuchen Sie einen der folgenden Problembereiche:

    • Gerätekonfiguration, z. B. JSON Konfigurationsdateien im /configs/ Ordner.

    • Geräteschnittstelle Überprüfen Sie die Protokolle, um festzustellen, welche Schnittstelle fehlschlägt.

    • Geräte-Tools Stellen Sie sicher, dass die Toolchains zum Erstellen und Flashen des Gerätes korrekt installiert und konfiguriert sind.

    • Stellen Sie für FRQ 1.x.x sicher, dass eine saubere, geklonte Version des kostenlosen RTOS Quellcodes verfügbar ist. Kostenlose RTOS Versionen sind entsprechend der kostenlosen Version gekennzeichnet. RTOS Verwenden Sie die folgenden Befehle, um eine bestimmte Version des Codes zu klonen:

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

Beheben Sie Fehler bei der Gerätekonfiguration

Wenn Sie Free verwenden IDTRTOS, 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ührungUUID, auf die execution-id in dieser Dokumentation verwiesen 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 for Free generierten Fehlercodes erklärtRTOS:

Fehlercode Name des Fehlercodes Mögliche Ursache Fehlerbehebung

201

InvalidInputError

Felder in device.json, config.json oder userdata.json fehlen entweder oder haben ein falsches Format.

Stellen Sie sicher, dass die Pflichtfelder in den aufgelisteten Dateien nicht fehlen und dass sie das erforderliche Format aufweisen. Weitere Informationen finden Sie unter Erster Test Ihres Mikrocontroller-Boards.

202

ValidationError

Felder in device.json, config.json oder userdata.json enthalten ungültige Werte.

Überprüfen Sie die Fehlermeldung auf der rechten Seite des Fehlercodes im Bericht:

  • Ungültige AWS Region — Geben Sie eine gültige AWS Region in Ihrer config.json Datei an. Weitere Informationen zu AWS Regionen finden Sie unter Regionen und Endpunkte.

  • Ungültige AWS Anmeldeinformationen — Legen Sie gültige AWS Anmeldeinformationen auf Ihrem Testcomputer fest (über Umgebungsvariablen oder die Anmeldeinformationsdatei). Überprüfen Sie, ob das Authentifizierungsfeld korrekt konfiguriert ist. Weitere Informationen finden Sie unter Erstellen und konfigurieren Sie ein AWS Konto.

203

CopySourceCodeError

Der kostenlose RTOS Quellcode konnte nicht in das angegebene Verzeichnis kopiert werden.

Überprüfen Sie Folgendes:

  • Prüfen Sie, ob ein gültiger sourcePath in der Datei userdata.json angegeben ist.

  • Löschen Sie den build Ordner unter dem Verzeichnis Kostenloser RTOS Quellcode, falls er existiert. Weitere Informationen finden Sie unter Konfiguration von Build-, Flash- und Testeinstellungen.

  • Windows hat eine Zeichenbeschränkung für Dateipfadnamen. Ein langer Dateipfadname verursacht einen Fehler.

204

BuildSourceError

Der kostenlose RTOS Quellcode konnte nicht kompiliert werden.

Überprüfen Sie Folgendes:

  • Überprüfen Sie, ob die Informationen unter buildTool in der Datei userdata.json korrekt sind.

  • Wenn Sie cmake als Build-Tool verwenden, stellen Sie sicher, dass {{enableTests}} im buildTool-Befehl angegeben ist. Weitere Informationen finden Sie unter Konfiguration von Build-, Flash- und Testeinstellungen.

  • Wenn Sie IDT beispielsweise kostenlos RTOS in einen Dateipfad auf Ihrem System extrahiert haben, der Leerzeichen enthält, benötigen Sie möglicherweise zusätzliche Anführungszeichen in Ihren Build-BefehlenC:\Users\My Name\Desktop\, um sicherzustellen, dass die Pfade korrekt analysiert werden. Das Gleiche wird möglicherweise für Ihre Flash-Befehle benötigt.

205

FlashOrRunTestError

IDTFree RTOS kann auf Ihrem weder flashen noch Free RTOS ausführenDUT.

Überprüfen Sie, ob die Informationen unter flashTool in der Datei userdata.json korrekt sind. Weitere Informationen finden Sie unter Konfiguration von Build-, Flash- und Testeinstellungen.

206

StartEchoServerError

IDTFree RTOS kann den Echo-Server für die WiFi oder Secure Socket-Tests nicht starten.

Stellen Sie sicher, dass die unter echoServerConfiguration in Ihrer userdata.json-Datei konfigurierten Ports nicht von der Firewall oder den Netzwerkeinstellungen verwendet oder blockiert werden.

Fehler beim Parsen der Konfigurationsdatei debuggen

Gelegentlich kann ein Tippfehler in einer JSON Konfiguration zu Analysefehlern führen. In den meisten Fällen ist das Problem darauf zurückzuführen, dass in Ihrer Datei eine Klammer, ein Komma oder ein Zitat weggelassen wird. JSON IDTfor Free RTOS führt eine JSON Überprüfung 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 Ihrem IDE Texteditor wie Atom oder Sublime oder über ein Online-Tool wie durchführen. JSONLint

Debuggen, Testergebnisse analysieren, Fehler analysieren

Beim Ausführen einer Testgruppe werden beispielsweise von FreeRTOS-Libraries-Integration-TestsFull PKCS11 _Core FullTransportInterfaceTLS, Full _Onboard_, Full PKCS11 _Onboard_ECC, Full PKCS11 _ _RSA, Full PKCS11 _ PreProvisioned _ oder ECC OTACore, IDT for FreeRSA, die Testergebnisse des Testgeräts mit der RTOS seriellen Verbindung analysiert. PKCS11 PreProvisioned Manchmal können zusätzliche serielle Ausgänge am Gerät die Auswertung der Testergebnisse beeinträchtigen.

Im oben genannten Fall werden seltsame Gründe für das Scheitern eines Testfalls ausgegeben, z. B. Zeichenfolgen, die von nicht verwandten Geräteausgängen stammen. Die RTOS Testfall-Protokolldatei von IDT For Free (die alle seriellen Ausgaben IDT enthält, die Free während des Tests erhalten RTOS hat) kann Folgendes enthalten:

<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 Free RTOS das Testergebnis erkennt, das ist PASS.

Überprüfen Sie Folgendes, um ein optimales Testen zu gewährleisten.

  • Stellen Sie sicher, dass die auf dem Gerät verwendeten Protokollierungsmakros threadsicher sind. Weitere Informationen finden Sie unter Implementieren der Bibliotheksprotokollierungsmakros.

  • Stellen Sie sicher, dass die serielle Verbindung während der Tests nur minimal ausgibt. Andere Geräteausgänge können ein Problem darstellen, selbst wenn Ihre Protokollierungsmakros ordnungsgemäß threadsicher sind, da die Testergebnisse während des Tests in separaten Aufrufen ausgegeben werden.

Ein IDT kostenloses RTOS Testfallprotokoll würde idealerweise eine unterbrechungsfreie 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 debuggen

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

Wenn Sie die reeRTOSIntegrity F-Testgruppe 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 ausführen, können Sie herausfinden, welchen markierten Zweig des IDT 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 freien RTOS Port ohne Änderungen an den Dateien und der Ordnerstruktur zu qualifizieren, stellen Sie sicher, dass keine der in den Abschnitten 'exhaustive' und 'minimal' der checksums.json Datei aufgelisteten Dateien geändert wurde. Stellen Sie sicher, dass keine der Dateien im Abschnitt 'minimal' geändert wurde, um die Ausführung mit einer SDK Konfiguration durchzuführen.

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

Fehler bei FullWiFi Testgruppen debuggen

Wenn Sie FRQ 1.x.x verwenden und in der FullWiFi Testgruppe Fehler auftreten und der "AFQP_WiFiConnectMultipleAP" Test fehlschlägt, kann dies daran liegen, dass sich beide Access Points nicht im selben Subnetz befinden wie der Hostcomputer, auf dem der Computer läuft. IDT Stellen Sie sicher, dass sich beide Access Points im selben Subnetz befinden wie der Hostcomputer, auf dem der Computer läuft. IDT

Fehler „Erforderlicher Parameter fehlt“ beheben

Da neue Funktionen IDT kostenlos hinzugefügt werdenRTOS, 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. IDTfor Free RTOS validiert Ihre JSON Konfigurationsdatei-Schemas, um sicherzustellen, dass die neueste unterstützte Version verwendet wurde.

Debuggen Sie die Fehler „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:

  • Stellen Sie sicher, dass der in Ihrem Ausführungsbefehl enthaltene Poolname tatsächlich vorhanden ist. Auf diesen wird direkt über Ihre device.json-Datei verwiesen.

  • Stellen Sie sicher, dass die Geräte in Ihrem Pool über die richtigen Konfigurationsparameter verfügen.

Debug-Fehler „Der Beginn der Testergebnisse konnte nicht gefunden werden“

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

  • Stellen Sie sicher, dass das zu testende Gerät eine stabile Verbindung zu Ihrem Host-Computer hat. Sie können in der Protokolldatei nach einem Test suchen, der diese Fehler anzeigt, um zu sehen, was empfangen IDT wird.

  • Wenn Sie FRQ 1.x.x verwenden und das zu testende Gerät über ein langsames Netzwerk oder eine andere Schnittstelle verbunden ist oder Sie das Kennzeichen „--------- STARTING TESTS ---------“ nicht zusammen mit anderen Ausgaben der Gruppe Kostenlose RTOS Tests in einem Gruppenprotokoll sehen, können Sie versuchen, den Wert von in Ihrer Benutzerdatenkonfiguration zu erhöhen. RTOS testStartDelayms Weitere Informationen finden Sie unter Konfiguration von Build-, Flash- und Testeinstellungen.

Debuggen Sie die Fehler „Testfehler: erwartete __ Ergebnisse, aber es wurden ___ gesehen“

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

Debuggen Sie den Fehler „________ wurde aufgrund von Einschränkungen nicht ausgewählt“ ConditionalTests

Das bedeutet, dass Sie einen Test auf einem Gerätepool ausführen, der mit dem Test nicht kompatibel ist. Dies kann bei den OTA E2E-Tests passieren. Beispielsweise haben Sie beim Ausführen der OTADataplaneMQTT Testgruppe und in Ihrer device.json Konfigurationsdatei „Nein“ oder OTADataPlaneProtocol „OTAals“ ausgewählt. HTTP Die Testgruppe, die Sie ausführen möchten, muss Ihrer device.json Funktionsauswahl entsprechen.

Debuggen Sie ein IDT Timeout bei der Überwachung der Geräteausgabe

IDTkann aus einer Reihe von Gründen ein Timeout auftreten. 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 falsch analysiert wurden. IDT Ein Grund könnten die verschachtelten Protokollmeldungen in der Mitte der Testergebnisse sein. Sollte dies der Fall sein, finden Sie im Leitfaden zur kostenlosen RTOS Portierung weitere Informationen zur Einrichtung der UNITY Logs.

Ein weiterer Grund für ein Timeout bei der Überwachung der Geräteausgabe könnte sein, dass ein Gerät nach einem einzigen TLS Testfallfehler neu gestartet wird. Das Gerät führt dann das Flash-Image aus und verursacht eine Endlosschleife, die in den Protokollen zu sehen ist. Stellen Sie in diesem Fall sicher, dass Ihr Gerät nach einem fehlgeschlagenen Test nicht neu gestartet wird.

Debuggen Sie den Fehler „Nicht autorisiert, auf die Ressource zuzugreifen“

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

Fehler im Netzwerktest debuggen

IDTStartet für netzwerkbasierte Tests einen Echo-Server, der eine Verbindung zu einem nicht reservierten Port auf dem Host-Computer herstellt. Wenn Sie aufgrund von Timeouts oder nicht verfügbaren Verbindungen bei den Tests WiFi oder Secure Sockets auf Fehler stoßen, stellen Sie sicher, dass Ihr Netzwerk so konfiguriert ist, dass Datenverkehr zu konfigurierten Ports im Bereich 1024 bis 49151 zugelassen wird.

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:

  • Windows: netsh advfirewall firewall show rule name=all | grep port

  • Linux: sudo netstat -pan | grep port

  • macOS: netstat -nat | grep port

OTAAktualisierungsfehler aufgrund der Payload derselben Version

Wenn OTA Testfälle fehlschlagen, weil sich dieselbe Version auf dem Gerät befindet, nachdem eine ausgeführt OTA wurde, kann dies daran liegen, dass Ihr Build-System (z. B. cmake) die Änderungen am kostenlosen RTOS Quellcode nicht bemerkt IDT und keine aktualisierte Binärdatei erstellt. Dies führt OTA dazu, dass er mit derselben Binärdatei ausgeführt wird, die sich derzeit auf dem Gerät befindet, und der Test schlägt fehl. Um Fehler beim OTA Update zu beheben, stellen Sie zunächst sicher, dass Sie die neueste unterstützte Version Ihres Build-Systems verwenden.

OTATestfehler im PresignedUrlExpired Testfall

Eine Voraussetzung für diesen Test ist, dass die OTA Aktualisierungszeit mehr als 60 Sekunden betragen sollte, da der Test sonst 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 Sie Geräteschnittstellen- und Portfehler

Dieser Abschnitt enthält Informationen zu den GeräteschnittstellenIDT, über die Sie eine Verbindung zu Ihren Geräten herstellen.

Unterstützte Plattformen

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

  • Linux: /dev/tty*

  • macOS: /dev/tty.* oder /dev/cu.*

  • Windows: COM *

So überprüfen Sie den Geräteport:

  • Öffnen Sie unter Linux/macOS ein Terminal und führen Sie ls /dev/tty* aus.

  • Öffnen Sie unter macOS ein Terminal und führen Sie ls /dev/tty.* oder ls /dev/cu.* aus.

  • Öffnen Sie in Windows Sie den Geräte-Manager und erweitern Sie die Gruppe mit den seriellen Geräten.

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

  • Stellen Sie unter Linux sicher, dass das Paket udev installiert ist, und führen Sie dann udevadm info –name=PORT aus. Dieses Dienstprogramm gibt die Gerätetreiberinformationen aus, mit deren Hilfe Sie überprüfen können, ob Sie den richtigen Port verwenden.

  • Öffnen Sie für macOS Launchpad und suchen Sie nach System Information.

  • Öffnen Sie in Windows Sie den Geräte-Manager und erweitern Sie die Gruppe mit den seriellen Geräten.

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:

  • Ein Datenport zum Flashen des Geräts.

  • Ein Leseport zum Lesen der Ausgabe.

    Sie müssen den richtigen Leseport in Ihrer device.json-Datei festlegen. Andernfalls kann das Lesen der Ausgabe vom Gerät fehlschlagen.

    Vergewissern Sie sich bei mehreren Ports, dass Sie den Leseport des Geräts in Ihrer device.json-Datei verwenden. Wenn Sie beispielsweise ein WRover Espressif-Gerät anschließen und die beiden ihm zugewiesenen Anschlüsse als /dev/ttyUSB0 und /dev/ttyUSB1 /dev/ttyUSB1 in Ihrer device.json Datei verwenden.

Folgen Sie derselben Logik in Windows.

Lesen von Gerätedaten

IDTfor Free RTOS 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:

  • Baudrate: 115200

  • Datenbits: 8

  • Parität: Keine

  • Stop-Bits: 1

  • Flusssteuerung: Keine

Diese Einstellungen werden von IDT for Free RTOS 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:

  • Kostenlos, wenn der Build oder das Flashen auf Ihrem Gerät RTOS fehlschlägt.

  • Das Code Composer Studio-Installationsprogramm stürzt ab.

  • In der Konsole wird keine Protokollausgabe während des Build- oder Flash-Prozesses angezeigt.

  • Der Build-Befehl versucht, im GUI Modus zu starten, auch wenn er als Headless aufgerufen wird.

Protokollierung

IDTDie RTOS Protokolle werden kostenlos an einem einzigen Ort gespeichert. Im IDT Stammverzeichnis sind diese Dateien verfügbar unterresults/execution-id/:

  • FRQ_Report.xml

  • awsiotdevicetester_report.xml

  • logs/test_group_id__test_case_id.log

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 RTOS Free-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 den 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 enthalten die vollständige Build- und Flash-Befehlsausgabe, die Ausgabe der Testausführung und eine ausführlichere AWS IoT Device Tester Konsolenausgabe.

Probleme mit dem S3-Bucket

Wenn Sie CTRL+C während des Laufens drückenIDT, IDT wird ein Bereinigungsvorgang gestartet. 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 bei IDT der nächsten Ausführung fehlschlagen werden.

Wenn Sie CTRL+C die Taste zum Beenden drückenIDT, 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.

Beheben Sie Timeout-Fehler

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.

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
./devicetester_linux run-suite --suite-id FRQ_1.0.1 --pool-id DevicePool1 --timeout-multiplier 2.5

Mobilfunkfunktion und Gebühren AWS

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

Richtlinie zur Erstellung von Qualifikationsberichten

Qualifikationsberichte werden nur für Versionen AWS IoT Device Tester (IDT) generiert, die kostenlose RTOS 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.

DatenschutzNutzungsbedingungen für die WebsiteCookie-Einstellungen
© 2025, Amazon Web Services, Inc. oder Tochtergesellschaften. Alle Rechte vorbehalten.