I2C WinRT – Lesetests (EEPROM erforderlich)
Die I2C-Tests führen Funktions- und Belastungstests von I2C-Controllern durch, die dem Benutzermodus über die Windows.Devices.I2c-WinRT-APIs ausgesetzt sind. Die Tests sind in zwei Teile aufgeteilt – grundlegende Funktions- und Belastungstests und fortgeschrittene Funktionstests. Der Prüfumfang der grundlegenden Funktionsprüfungen umfasst:
- Überprüfung, ob auf einen I2C-Controller mit dem angegebenen Anzeigenamen im Benutzermodus zugegriffen werden kann.
- Verifizierung, dass Daten über einen Bereich von Taktraten und Pufferlängen bis zu 8 Byte (EEPROM-Seitengröße) korrekt geschrieben werden.
- Verifizierung, dass Daten über einen Bereich von Taktraten und Pufferlängen korrekt gelesen werden.
- Verifizierung, dass Schreib-Neustart-Lese-Sequenzen (WriteReads) über einen Bereich von Taktgeschwindigkeiten und Pufferlängen korrekt ausgeführt werden.
- Verifizierung, dass der Treiber STATUS_NO_SUCH_DEVICE zurückgibt, wenn ein Schreib-, Lese- oder WriteRead-Versuch an eine nicht bestätigte Sekundärgerätadresse unternommen wird. Dies wird von I2cDevice::Write/Read/WriteRead() als HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND) und von I2cDevice::WritePartial/ReadPartial/WriteReadPartial() als I2cTransferStatus::SlaveAddressNotAcknowledged gemeldet.
- Verifizierung, dass die APIs und Treiber unter Stressbedingungen korrekt funktionieren. Die Belastungstests schreiben und lesen aus zwei EEPROMs gleichzeitig mit separaten Gerätehandles über einen längeren Zeitraum.
Der Prüfumfang der erweiterten Funktionstests umfasst:
- Überprüfung des korrekten Schreibens der Daten für Pufferlängen bis 16384 Byte.
- Verifizierung, dass eine I2C-Neustartbedingung als Reaktion auf eine WriteRead-Sequenz generiert wird.
- Verifizierung, dass, wenn das Slave-Gerät NAKs gibt, während der Master immer noch Bytes schreibt, der Treiber die Anforderung mit STATUS_SUCCESS abschließt und die tatsächliche Anzahl der geschriebenen Bytes durch die Anforderungsinformationen meldet. Dies wird als partielle Übertragung bezeichnet und von WritePartial() und WriteReadPartial() als I2cTransferStatus::PartialTransfer gemeldet.
- Überprüfung, dass eine Taktdehnung bis zu 500 ms zulässig ist und nicht dazu führt, dass die Übertragung fehlschlägt.
- Verifizierung, dass, wenn das Sekundärgerät die Taktleitung für eine längere Dauer (mehr als 10 Sekunden) niedrig hält, der Treiber die Übertragung innerhalb von höchstens 10 Sekunden mit einem Fehlercode abschließt. Der Fehlercode sollte STATUS_IO_TIMEOUT lauten, dies wird jedoch aus Kompatibilitätsgründen nicht überprüft.
Die grundlegenden Funktionstests und Belastungstests laufen gegen zwei extern angeschlossene EEPROMs. Die erweiterten Funktionstests laufen auf einem mbed LPC1768 mit benutzerdefinierter Firmware. Der mbed LPC1768 ist eine beliebte Mikrocontroller-Prototyping-Plattform, die bei einer Vielzahl von Online-Händlern, darunter Sparkfun, Digikey und Adafruit, erworben werden kann. Die Aktualisierung der mbed-Firmware ist so einfach wie das Ziehen und Ablegen einer Datei. Der Firmware-Quellcode ist auf github verfügbar. Anweisungen zum Vorbereiten des mbed und zum Ausführen der Tests finden Sie unten.
Testdetails
| Spezifikationen |
|
| Plattformen | |
| Unterstützte Versionen |
|
| Voraussichtliche Laufzeit (in Minuten) | 5 |
| Kategorie | Entwicklung |
| Zeitüberschreitung (in Minuten) | 10 |
| Neustart erforderlich | false |
| Erfordert eine spezielle Konfiguration | true |
| Typ | automatic |
Zusätzliche Dokumentation
Tests in diesem Funktionsbereich enthalten möglicherweise zusätzliche Dokumentation, einschließlich Informationen zu Voraussetzungen, Einrichtung und Fehlerbehebung, die in den folgenden Themen zu finden sind:
Ausführen des Tests
Ausführen der grundlegenden Funktions- und Belastungstests
Sie benötigen die folgende Hardware, um die Tests durchzuführen:
- Atmel AT24HC serial EEPROMs qt. 2
- 10k resistor qt. 2
- Breadboard
- Leitungen
Verdrahten Sie die EEPROMs wie im folgenden Diagramm gezeigt und verbinden Sie SDA und SCL mit Ihrem Testobjekt.
Sie können jetzt die grundlegenden Funktions- und Belastungstests vom HLK-Manager aus planen.
Ausführen der erweiterten Funktionstests
Die erweiterten Funktionstests verifizieren das NACKing-Verhalten, hängende Busbedingungen, Clock-Stretching und wiederholte Starts. Für die Tests muss ein mbed LPC1768 mit benutzerdefinierter Firmware an das zu testende Gerät angeschlossen werden. Bevor Sie die Tests ausführen, müssen Sie die HLK-Firmware auf den mbed LPC1768 laden. So aktualisieren Sie die Firmware:
- Schließen Sie den mbed LPC1768 über USB an Ihren PC an. Es wird als Wechseldatenträger auf Ihrem PC angezeigt.
- Öffnen Sie das Laufwerk im Datei-Explorer
- Kopieren Sie c:\Program Files (x86)\Windows Kits\10\Hardware Lab Kit\Tests\x86\iot\busses-tester-mbed_LPC1768.bin in die mbed
- Drücken Sie die Taste am mbed, um den Mikrocontroller zurückzusetzen
Als nächstes verdrahten Sie das mbed mit Ihrem zu testenden Gerät. Schließen Sie das mbed über USB an Ihr zu testendes Gerät an. Stellen Sie dann die I2C-Verbindungen her (mbed pinout),
- Verbinden Sie mbed-Pin 9 (P0.0/SDA) mit dem SDA-Pin Ihres zu testenden Geräts
- Verbinden Sie mbed Pin 10 (P0.1/SCL) mit dem SCL-Pin Ihres Testobjekts
- Verbinden Sie mbed GND mit einem GND-Pin Ihres zu testenden Geräts
Das mbed verfügt über interne Pull-up-Widerstände, die auf den SDA- und SCL-Leitungen aktiviert sind, und benötigt keine externen Pull-up-Widerstände.
Sie können jetzt die erweiterten Funktionstests vom HLK-Manager aus planen.
Problembehandlung
Informationen zur allgemeinen Problembehandlung bei HLK-Testfehlern finden Sie unter Problembehandlung bei Windows HLK-Testfehlern.
Wir empfehlen, die Tests in der Befehlszeile auszuführen, um Einblicke in Fehler zu erhalten und Lösungen schnell zu iterieren. So führen Sie die Tests in der Befehlszeile aus:
Kopieren Sie %programfiles(x86)%\Windows Kits\10\Testing\Runtimes\TAEF\<arch>\MinTe nach c:\data\minte
Kopieren Sie Windows.Devices.LowLevel.UnitTests.dll aus %programfiles(x86)%\Windows Kits\10\Hardware Lab Kit\Tests\<arch>\iot nach c:\data auf Ihrem Gerät.
Telnet oder ssh in Ihr Gerät
Wechseln Sie in das Verzeichnis c:\data
Führen Sie die Tests aus:
minte\te windows.devices.lowlevel.unittests.dll /name:I2c*
Verwendung des Befehlszeilentests:
minte\te windows.devices.lowlevel.unittests.dll [/name:test_name] [/select:select_clause] [/p:I2cFriendlyName=friendly_name] [/p:Duration=duration]
- test_name – der Name des auszuführenden Tests, der Platzhalter enthalten kann. Beispiele: /name:I2c*, /name:I2cEepromWriteTests#metadataSet0::VerifyWrite#metadataSet0
- select_clause – eine TAEF-Auswahlklausel. Beispiel: /select:"@name='I2c*' and not(@name='I2cTestsEx*')"
- friendly_name – Der freundliche Name des zu testenden I2C-Controllers. Wenn weggelassen, wird der erste aufgezählte Controller verwendet. Beispiele: /p:I2cFriendlyName=I2C0
- Dauer - wie lange Stresstests durchgeführt werden sollen. Beispiele: /p:Duration=10s (10 Sekunden), /p:Duration=1m (1 Minute), /p:Duration=2h (2 Stunden), /p:Duration=1d (1 Tag)
Beispiele:
Um die grundlegenden Funktionstests durchzuführen,
minte\te windows.devices.lowlevel.unittests.dll /select:"@name='I2c*' and not(@name='I2cTestsEx*')"
Um die erweiterten Funktionstests auszuführen,
minte\te windows.devices.lowlevel.unittests.dll /name:I2cTestsEx::*
Um die Tests für eine bestimmte I2C-Controller-Instanz auszuführen, übergeben Sie den Anzeigenamen an den I2cFriendlyName-Testparameter,
minte\te windows.devices.lowlevel.unittests.dll /name:I2c* /p:I2cFriendlyName=I2C0
Um einen bestimmten Test auszuführen, übergeben Sie den vollständigen Testnamen an den Parameter /name:
minte\te windows.devices.lowlevel.unittests.dll /name:I2cNonexistentSlaveAddressTests::TestWriteRead
Führen Sie die Belastungstests für die empfohlene Dauer von 8 Stunden aus
minte\te windows.devices.lowlevel.unittests.dll /name:I2cStressTests::StressIoConcurrent /p:Duration=8h
Ein Tool, das bei der manuellen Fehlerbehebung helfen kann, ist I2cTestTool. I2cTestTool ist ein einfaches Dienstprogramm für die Interaktion mit I2C über die Befehlszeile.
Weitere Informationen
Parameter
| Parametername | Parameterbeschreibung |
|---|---|
| I2cFriendlyName | Der Anzeigename des zu testenden I2C-Controllers (z. B. I2C0). |