Test di trasferimento di SPI WinRT IO (mbed LPC1768 Obbligatorio)
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 nome descrittivo specificato sia accessibile da usermode.
- 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 strip LED e convertitori digitali, richiedono un segnale di orologio senza interruzioni.
- Verifica che la velocità dell'orologio effettiva usata sia compresa nel 15% del valore richiesto.
- Verifica che quando viene tentato 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à sul 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 piattaforma di prototipazione di microcontroller popolare che può essere acquistata da un'ampia gamma di rivenditori online, tra cui Sparkfun, Digikey e Adafruit. La programmazione dell'immagine del firmware di test è semplice come trascinare e eliminare l'immagine del firmware nel dispositivo di archiviazione di massa. Il codice sorgente del firmware è disponibile in github. Istruzioni dettagliate sulla preparazione dei test mbed ed esecuzione dei test sono disponibili di seguito.
Dettagli del test
Specifiche |
|
Piattaforme | |
Versioni supportate |
|
Tempo di esecuzione previsto (in minuti) | 15 |
Categoria | Sviluppo |
Timeout (in minuti) | 30 |
Richiede il riavvio | false |
Richiede una configurazione speciale | true |
Tipo | automatic |
Documentazione aggiuntiva
I test in questa area di funzionalità potrebbero avere documentazione aggiuntiva, inclusi prerequisiti, configurazione e 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 jumper
Prima di tutto, è necessario caricare il firmware di test nel mbed:
- Collegare l'LPC1768 mbed tramite USB al PC. Verrà visualizzata come unità rimovibile nel PC.
- Aprire l'unità in Esplora file
- Copiare c:\Programmi (x86)\Windows Kits\10\Hardware Lab Kit\Testing\x86\iot\busses-tester-mbed_LPC1768.bin nell'unità
- Premere il pulsante sul mbed per reimpostare il microcontroller
Successivamente, collegare il mbed al controller SPI in fase di test. Per attivare mbed, è possibile collegarlo tramite USB al dispositivo in fase di test o connettere i pin VIN e GND direttamente ai pin di alimentazione nel dispositivo in fase di test. Effettuare le connessioni seguenti tra il dispositivo in fase di test e mbed: (pinout mbed),
- Connettere mbed pin 13 (P0.15/SCK0) al pin SCK nel dispositivo in fase di test
- Connettere mbed pin 30 (P0.4/CAP2.0) al pin SCK nel dispositivo in fase di test (questo pin viene usato per la misurazione dell'orologio precisa)
- Connettere mbed pin 11 (P0.18/MOSI0) al pin MOSI nel dispositivo in fase di test
- Connettere mbed pin 12 (P0.17/MISO0) al pin MISO nel dispositivo in fase di test
- Connettere mbed pin 14 (P0.16/SSEL0) al pin Chip Select nel dispositivo in fase di test
- Connettere mbed GND a un pin GND nel dispositivo in fase di test
È ora possibile pianificare i test in HLK Studio.
Risoluzione dei problemi relativi
Per la risoluzione dei problemi generici 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 collegare un analizzatore di logica, ad esempio una sala. Può essere difficile o impossibile determinare la causa di un errore senza la possibilità di controllare il traffico del bus.
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\Testing<\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 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 : il nome del test da eseguire che può includere caratteri jolly. Esempi: /name:SpiHlk*, /name:SpiHlkTests::VerifyClockFrequency#metadataSet0
- friendly_name : il nome descrittivo del controller SPI in fase di test. Se omesso, viene usato il primo controller enumerato. Esempi: /p:SpiFriendlyName=SPI1
- clock_frequency : forzare un test per usare la frequenza di orologio specificata. Per impostazione predefinita, la frequenza dell'orologio proviene dai dati di test, progettati per dare copertura su un intervallo di frequenze. Questo parametro deve essere omesso in circostanze normali. Esempio: /p:ClockFrequency=15000000
- data_bit_length : forzare un test per 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). |