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/
zu erstellen. Die einzelnen Testgruppenprotokolle befinden sich im Verzeichnis execution-id
results/
. 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. execution-id
/logsresults/
Die Informationen in dieser Datei beinhalten Folgendes: execution-id
/logs/test_group_id
__test_case_id
.log
-
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:
-
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. -
Lesen Sie die Konsolenausgabe, um Informationen zu finden, z. B. zur Ausführung UUID und zur aktuellen Ausführung von Aufgaben.
-
Suchen Sie in der Datei
FRQ_Report.xml
nach Fehleranweisungen für jeden Test. Dieses Verzeichnis enthält Ausführungsprotokolle für jede Testgruppe. -
Schauen Sie in den Protokolldateien unter nach
/results/
.execution-id
/logs -
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/
. 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 execution-id
/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 |
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 |
Überprüfen Sie die Fehlermeldung auf der rechten Seite des Fehlercodes im Bericht:
|
203 |
CopySourceCodeError |
Der kostenlose RTOS Quellcode konnte nicht in das angegebene Verzeichnis kopiert werden. |
Überprüfen Sie Folgendes:
|
204 |
BuildSourceError |
Der kostenlose RTOS Quellcode konnte nicht kompiliert werden. |
Überprüfen Sie Folgendes:
|
205 |
FlashOrRunTestError |
IDTFree RTOS kann auf Ihrem weder flashen noch Free RTOS ausführenDUT. |
Überprüfen Sie, ob die Informationen unter |
206 |
StartEchoServerError |
IDTFree RTOS kann den Echo-Server für die WiFi oder Secure Socket-Tests nicht starten. |
Stellen Sie sicher, dass die unter |
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-Tests
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
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 freertos
list-supported-products
Befehl ausführen, können Sie herausfinden, welchen markierten Zweig des IDT
Repositorys Sie verwenden sollten.freertos
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
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 'freertos
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
Verzeichnis geändert haben, stellen Sie sicher, dass Sie Ihre SDK freertos
userdata
Datei korrekt konfiguriert haben. Andernfalls überprüft der Integritätsprüfer alle Dateien im
Verzeichnis.freertos
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
im Verzeichnis test_group_id
__test_case_id
.logresults/
explizit alle fehlenden Parameter auf. IDTfor Free RTOS validiert Ihre JSON Konfigurationsdatei-Schemas, um sicherzustellen, dass die neueste unterstützte Version verwendet wurde.execution-id
/logs
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/
. Um dieses Problem zu beheben, fügen Sie die execution-id
/logsAWS 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.*
oderls /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 dannudevadm info –name=
aus. Dieses Dienstprogramm gibt die Gerätetreiberinformationen aus, mit deren Hilfe Sie überprüfen können, ob Sie den richtigen Port verwenden.PORT
-
Ö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 Ihrerdevice.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/
sind die wichtigsten Protokolle, die Sie untersuchen sollten. test_group_id
__test_case_id
.logFRQ_Report.xml
enthält Informationen dazu, für welche Testfälle Fehler mit einer bestimmten Fehlermeldung aufgetreten sind. Anschließend können Sie logs/
verwenden, um das Problem genauer zu analysieren und so einen besseren Kontext zu erhalten. test_group_id
__test_case_id
.log
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/
verwendet wird. Einzelne Testfallprotokolle befinden sich im Verzeichnis execution-id
results/
. 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. execution-id
/logsresults/
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.execution-id
/logs/test_group_id
__test_case_id
.log
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
.
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