Test di verifica stride di SPI WinRT
I test SPI eseguono test funzionali e di stress dei controller SPI esposti alla modalità utente tramite le API Windows.Devices.Spi WinRT. L'ambito dei test include:
- Verifica che un controller SPI con il nome descrittivo specificato sia accessibile dalla modalità utente.
- Verifica che i dati vengano inviati e ricevuti correttamente in un intervallo di modalità SPI, frequenze di clock, lunghezze dei bit di dati e lunghezze di trasferimento.
- La verifica non contiene lacune tra i byte all'interno di un trasferimento. Alcuni dispositivi, ad esempio strisce LED e convertitori digitali analogici, richiedono un segnale di clock ininterrotto.
- Verifica che la velocità di clock effettiva usata sia compresa nel 15% del valore richiesto.
- Verifica che quando si tenta un trasferimento con una lunghezza del buffer che non è un multiplo dello stride, il trasferimento non è riuscito con STATUS_INVALID_PARAMETER e non viene generata alcuna attività nel bus. Lo stride è determinato da DataBitLength come indicato di seguito:
| DataBitLength | Stride |
| 4 - 8 | 1 |
| 9 - 16 | 2 |
| 17 - 32 | 4 |
I test vengono eseguiti su un LPC1768 connesso esternamente. Mbed LPC1768 è una popolare piattaforma di prototipazione microcontroller che può essere acquistata da un'ampia gamma di rivenditori online, tra cui Sparkfun, Digikey e Adafruit. La programmazione dell'immagine mbed con l'immagine del firmware di test è semplice come il trascinamento e l'eliminazione dell'immagine del firmware nel dispositivo di archiviazione di massa. Il codice sorgente del firmware è disponibile in github. Di seguito sono riportate istruzioni dettagliate sulla preparazione dell'mbed e sull'esecuzione dei test.
Dettagli del test
| Specifiche |
|
| Piattaforme | |
| Versioni supportate |
|
| Tempo di esecuzione previsto (in minuti) | 5 |
| Categoria | Sviluppo |
| Timeout (in minuti) | 10 |
| Richiede il riavvio | false |
| Richiede una configurazione speciale | false |
| Tipo | automatic |
Documentazione aggiuntiva
I test in questa area di funzionalità potrebbero avere documentazione aggiuntiva, inclusi i prerequisiti, la configurazione e le informazioni sulla risoluzione dei problemi, disponibili negli argomenti seguenti:
Esecuzione del test
Per eseguire i test, è necessario disporre dell'hardware seguente:
- mbed LPC1768
- Breadboard
- Fili del ponticello
Prima di tutto, è necessario caricare il firmware di test nel mbed:
- Collegare mbed LPC1768 tramite USB al PC. Verrà visualizzato come unità rimovibile nel PC.
- Aprire l'unità in Esplora file
- Copiare c:\Programmi (x86)\Windows Kits\10\Hardware Lab Kit\Tests\x86\iot\busses-tester-mbed_LPC1768.bin nell'unità
- Premere il pulsante su mbed per reimpostare il microcontroller
Collegare quindi il mbed al controller SPI sottoposto a test. Per alimentare il mbed, è possibile collegarlo tramite USB al dispositivo sottoposto a test o connettere i pin VIN e GND direttamente ai pin di alimentazione nel dispositivo sottoposto a test. Stabilire le connessioni seguenti tra il dispositivo sottoposto a test e mbed: (pinout mbed),
- Connettere mbed pin 13 (P0.15/SCK0) al pin SCK nel dispositivo sottoposto a test
- Collegare il pin mbed 30 (P0.4/CAP2.0) al pin SCK nel dispositivo sottoposto a test (questo pin viene usato per la misurazione precisa dell'orologio)
- Connettere mbed pin 11 (P0.18/MOSI0) al pin MOSI nel dispositivo sottoposto a test
- Connettere mbed pin 12 (P0.17/MISO0) al pin MISO nel dispositivo sottoposto a test
- Connettere mbed pin 14 (P0.16/SSEL0) al pin Chip Select nel dispositivo sottoposto a test
- Connettere GND mbed a un pin GND nel dispositivo sottoposto a test
È ora possibile pianificare i test in HLK Studio.
Risoluzione dei problemi relativi
Per la risoluzione generica degli errori di test HLK, vedere Risoluzione dei problemi di test di Windows HLK.
È consigliabile eseguire i test nella riga di comando per ottenere informazioni dettagliate sugli errori e per eseguire rapidamente l'iterazione sulle soluzioni. È anche consigliabile associare un analizzatore della logica, ad esempio un salato. Può essere difficile o impossibile determinare la causa di un errore senza la possibilità di controllare il traffico degli autobus.
Ecco come eseguire i test nella riga di comando:
Copiare %programfiles(x86)%\Windows Kits\10\Testing\Runtimes\TAEF\<arch>\MinTe to c:\data\minte
Copiare Windows.Devices.LowLevel.UnitTests.dll da %programfiles(x86)%\Windows Kits\10\Hardware Lab Kit\Tests\<arch>\iot in c:\data nel dispositivo.
Telnet o ssh nel dispositivo
Modificare le directory in c:\data
Eseguire i test:
minte\te windows.devices.lowlevel.unittests.dll /name:SpiHlk*
Utilizzo dei test della riga di comando:
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 : nome del test da eseguire che può includere caratteri jolly. Esempi: /name:SpiHlk*, /name:SpiHlkTests::VerifyClockFrequency#metadataSet0
- friendly_name: nome descrittivo del controller SPI sottoposto a test. Se omesso, viene utilizzato il primo controller enumerato. Esempi: /p:SpiFriendlyName=SPI1
- clock_frequency : forzare un test per usare la frequenza di clock specificata. Per impostazione predefinita, la frequenza di clock proviene dai dati di test, progettata per fornire copertura su un intervallo di frequenze. Questo parametro deve essere omesso in circostanze normali. Esempio: /p:ClockFrequency=1500000
- data_bit_length: forzare un test a usare la lunghezza del bit di dati specificata. Esempio: /p:DataBitLength=9
- SpiMode: forzare un test per usare la modalità SPI specificata. Esempio: /p:SpiMode=2
- length: forzare un test a usare la lunghezza del buffer specificata per il trasferimento. Esempio: /p:length=128
- write_length : forzare un test TransferSequential per usare la lunghezza del buffer specificata per la parte di scrittura del trasferimento. Esempio: /p:WriteLength=8
- read_length : forzare un test TransferSequential per usare la lunghezza del buffer specificata per la parte di lettura del trasferimento. Esempio: /p:ReadLength=16
- extra_clocks : specificare una regolazione del numero di orologi per byte usati dai test quando si calcolano gli orari attivi del clock previsti per le misurazioni delle prestazioni, il rilevamento dei gap e la convalida della frequenza di clock. Ad esempio, il controller BCM2836 SPI attende un ciclo di clock aggiuntivo dopo ogni byte, quindi per compensare questo comportamento è necessario regolare le misurazioni. Esempio: /p:ExtraClocks=1.5
- /p:Verbose=true : attivare l'output dettagliato. Ciò causerà il dump di interi buffer nella console quando si verifica un errore. Per impostazione predefinita, viene visualizzato solo il primo byte non corrispondente.
Esempi:
Elencare i test disponibili:
minte\te windows.devices.lowlevel.unittests.dll /list
Eseguire i test di convalida di I/O:
minte\te windows.devices.lowlevel.unittests.dll /name:SpiHlkIoTests*
Eseguire i test di rilevamento dei gap:
minte\te windows.devices.lowlevel.unittests.dll /name:SpiHlkGapTests*
Eseguire i test di convalida della frequenza di clock e stride:
minte\te windows.devices.lowlevel.unittests.dll /name:SpiHlkTests*
Eseguire un test specifico su un'istanza del controller SPI specifica:
minte\te windows.devices.lowlevel.unittests.dll /name:SpiHlkIoTests#2::VerifyTransferSequential#metadataSet9 /p:SpiFriendlyName=SPI1
Uno strumento che può essere utile per la risoluzione dei problemi manuali è SpiTestTool. SpiTestTool è un'utilità semplice per interagire con SPI dalla riga di comando.
Altre informazioni
Parametri
| Nome parametro | Descrizione dei parametri |
|---|---|
| SpiFriendlyName | Nome descrittivo del controller SPI sottoposto a test (ad esempio SPI0). |