SPI WinRT – E/A-Übertragungstests (mbed LPC1768 erforderlich)
Die SPI-Tests führen Funktions- und Belastungstests von SPI-Controllern durch, die dem Benutzermodus über die Windows.Devices.Spi-WinRT-APIs ausgesetzt sind. Der Prüfumfang umfasst:
- Überprüfung, ob auf einen SPI-Controller mit dem angegebenen Anzeigenamen im Benutzermodus zugegriffen werden kann.
- Verifizierung, dass Daten über eine Reihe von SPI-Modi, Taktfrequenzen, Datenbitlängen und Übertragungslängen korrekt gesendet und empfangen werden.
- Überprüfung, dass keine Lücken zwischen Bytes innerhalb einer Übertragung vorhanden sind. Einige Geräte wie LED-Streifen und Analog-Digital-Wandler benötigen ein ununterbrochenes Taktsignal.
- Überprüfung, ob die tatsächlich verwendete Taktrate innerhalb von 15 % des angeforderten Werts liegt.
- Verifizierung, dass, wenn eine Übertragung mit einer Pufferlänge versucht wird, die kein Vielfaches der Schrittweite ist, die Übertragung mit STATUS_INVALID_PARAMETER fehlschlägt und keine Aktivität auf dem Bus erzeugt wird. Die Schrittweite wird von DataBitLength wie folgt bestimmt:
| DataBitLength | Stride |
| 4 – 8 | 1 |
| 9 – 16 | 2 |
| 17 – 32 | 4 |
Tests laufen gegen einen extern angeschlossenen mbed LPC1768. 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 Programmierung des mbed mit dem Test-Firmware-Image erfolgt einfach durch Ziehen und Ablegen des Firmware-Images auf den Massenspeicher. Der Firmware-Quellcode ist auf github verfügbar. Detaillierte Anweisungen zum Vorbereiten des mbed und zum Ausführen der Tests finden Sie unten.
Testdetails
| Spezifikationen |
|
| Plattformen | |
| Unterstützte Versionen |
|
| Voraussichtliche Laufzeit (in Minuten) | 15 |
| Kategorie | Entwicklung |
| Zeitüberschreitung (in Minuten) | 30 |
| 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
Sie benötigen die folgende Hardware, um die Tests durchzuführen:
- mbed LPC1768
- Breadboard
- Jumperdrähte
Zunächst müssen Sie die Test-Firmware auf das mbed laden:
- 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 auf das Laufwerk
- Drücken Sie die Taste am mbed, um den Mikrocontroller zurückzusetzen
Als nächstes verdrahten Sie das mbed mit Ihrem zu testenden SPI-Controller. Um das mbed mit Strom zu versorgen, können Sie es über USB an Ihr zu testendes Gerät anschließen oder die VIN- und GND-Pins direkt mit den Stromversorgungspins Ihres zu testenden Geräts verbinden. Stellen Sie die folgenden Verbindungen zwischen Ihrem zu testenden Gerät und dem mbed her: (mbed pinout),
- Verbinden Sie mbed Pin 13 (P0.15/SCK0) mit dem SCK-Pin Ihres zu testenden Geräts
- Verbinden Sie den mbed-Pin 30 (P0.4/CAP2.0) mit dem SCK-Pin Ihres zu testenden Geräts (dieser Pin wird zur präzisen Taktmessung verwendet)
- Verbinden Sie mbed Pin 11 (P0.18/MOSI0) mit dem MOSI-Pin Ihres zu testenden Geräts
- Verbinden Sie mbed Pin 12 (P0.17/MISO0) mit dem MISO-Pin Ihres zu testenden Geräts
- Verbinden Sie mbed Pin 14 (P0.16/SSEL0) mit dem Chip-Select-Pin Ihres zu testenden Geräts
- Verbinden Sie mbed GND mit einem GND-Pin Ihres zu testenden Geräts
Sie können die Tests jetzt in HLK Studio 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. Wir empfehlen außerdem, einen Logikanalysator wie einen Salae anzuschließen. Es kann schwierig oder unmöglich sein, die Ursache eines Ausfalls zu bestimmen, ohne den Busverkehr untersuchen zu können.
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:SpiHlk*
Verwendung des Befehlszeilentests:
minte\te windows.devices.lowlevel.unittests.dll [/name:test_name] [/p:SpiFriendlyName=friendly_name] [/p:ClockFrequency=clock_frequency] [/p:DataBitLength=data_bit_length] [/p:SpiMode=0|1|2|3] [/p:Length=length] [/p:WriteLength=write_length] [/p:ReadLength=read_length] [/p:ExtraClocks=extra_clocks] [/p:Verbose=true]
- test_name – der Name des auszuführenden Tests, der Platzhalter enthalten kann. Beispiele: /name:SpiHlk*, /name:SpiHlkTests::VerifyClockFrequency#metadataSet0
- friendly_name – Der Anzeigename des getesteten SPI-Controllers. Wenn weggelassen, wird der erste aufgezählte Controller verwendet. Beispiele: /p:SpiFriendlyName=SPI1
- clock_frequency – zwingt einen Test, die angegebene Taktfrequenz zu verwenden. Standardmäßig stammt die Taktfrequenz aus den Testdaten, die so ausgelegt sind, dass sie einen Bereich von Frequenzen abdecken. Dieser Parameter sollte unter normalen Umständen weggelassen werden. Beispiel: /p:ClockFrequency=1500000
- data_bit_length – zwingt einen Test, die angegebene Datenbitlänge zu verwenden. Beispiel: /p:DataBitLength=9
- SpiMode – erzwingt einen Test, um den angegebenen SPI-Modus zu verwenden. Beispiel: /p:SpiMode=2
- length – zwingt einen Test, die angegebene Pufferlänge für die Übertragung zu verwenden. Beispiel: /p:länge=128
- write_length – erzwingt einen TransferSequential-Test, um die angegebene Pufferlänge für den Schreibteil der Übertragung zu verwenden. Beispiel: /p:WriteLength=8
- read_length – erzwingt einen TransferSequential-Test, um die angegebene Pufferlänge für den Leseteil der Übertragung zu verwenden. Beispiel: /p:ReadLength=16
- extra_clocks – Geben Sie eine Anpassung an die Anzahl der Takte pro Byte an, die die Tests verwenden, wenn sie die erwarteten aktiven Taktzeiten für Leistungsmessungen, Lückenerkennung und Taktfrequenzvalidierung berechnen. Beispielsweise wartet der BCM2836-SPI-Controller nach jedem Byte einen zusätzlichen Taktzyklus, sodass die Messungen angepasst werden müssen, um dieses Verhalten zu kompensieren. Beispiel: /p:ExtraClocks=1.5
- /p:Verbose=true – schaltet die ausführliche Ausgabe ein. Dadurch werden bei einem Fehler ganze Puffer an die Konsole ausgegeben. Standardmäßig wird nur das erste nicht übereinstimmende Byte angezeigt.
Beispiele:
Verfügbare Tests auflisten:
minte\te windows.devices.lowlevel.unittests.dll /list
Führen Sie die IO-Validierungstests aus:
minte\te windows.devices.lowlevel.unittests.dll /name:SpiHlkIoTests*
Führen Sie die Lückenerkennungstests aus:
minte\te windows.devices.lowlevel.unittests.dll /name:SpiHlkGapTests*
Führen Sie die Validierung der Taktfrequenz und Stride-Tests durch:
minte\te windows.devices.lowlevel.unittests.dll /name:SpiHlkTests*
Führen Sie einen bestimmten Test für eine bestimmte SPI-Controller-Instanz durch:
minte\te windows.devices.lowlevel.unittests.dll /name:SpiHlkIoTests#2::VerifyTransferSequential#metadataSet9 /p:SpiFriendlyName=SPI1
Ein Tool, das bei der manuellen Fehlersuche helfen kann, ist SpiTestTool. SpiTestTool ist ein einfaches Dienstprogramm für die Interaktion mit SPI über die Befehlszeile.
Weitere Informationen
Parameter
| Parametername | Parameterbeschreibung |
|---|---|
| SpiFriendlyName | Der Anzeigename des zu testenden SPI-Controllers (z. B. SPI0). |