Test di lettura I2C WinRT (obbligatorio EEPROM)
I test I2C eseguono test funzionali e di stress dei controller I2C esposti alla modalità utente tramite le API Windows.Devices.I2c WinRT. I test sono suddivisi in due parti: test funzionali e di stress di base e test funzionali avanzati. L'ambito dei test dei test funzionali di base include:
- Verifica che un controller I2C con nome descrittivo specificato sia accessibile da usermode.
- Verifica che i dati vengano scritti correttamente su un intervallo di velocità di clock e lunghezze del buffer fino a 8 byte (dimensioni pagina EEPROM).
- Verifica che i dati vengano letti correttamente su un intervallo di velocità di clock e lunghezze del buffer.
- Verifica che le sequenze di lettura di scrittura (WriteRead) vengano eseguite correttamente su un intervallo di velocità di clock e lunghezze del buffer.
- Verifica che quando si tenta un indirizzo di scrittura, lettura o WriteRead di un indirizzo slave non riconosciuto, il driver restituisce STATUS_NO_SUCH_DEVICE. Questo viene segnalato da I2cDevice::Write/Read/WriteRead() come HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND) e viene segnalato da I2cDevice::WritePartial/ReadPartial/WriteReadPartial() come I2cTransferStatus::SlaveAddressNotAcknowledged.
- Verifica che le API e i driver funzionino correttamente in condizioni di stress. I test di stress scrivono e leggono da due EEPROMs simultaneamente con handle di dispositivo separati in una durata estesa.
L'ambito dei test dei test funzionali avanzati include:
- Verifica che i dati vengano scritti correttamente per le lunghezze del buffer fino a 16384 byte.
- Verifica che venga generata una condizione di riavvio I2C in risposta a una sequenza WriteRead.
- Verifica che quando il dispositivo slave NAK sta ancora scrivendo byte, il driver completa la richiesta con STATUS_SUCCESS e segnala il numero effettivo di byte scritti tramite le informazioni sulla richiesta. Viene chiamato trasferimento parziale e viene segnalato da WritePartial() e WriteReadPartial() come I2cTransferStatus::P artialTransferTransfer.
- La verifica che l'orologio che si estende fino a 500ms è consentito e non causa l'esito negativo del trasferimento.
- Verifica che quando il dispositivo slave contiene la linea di orologio bassa per una durata estesa (10+ secondi), il driver completa il trasferimento entro più di 10 secondi con un codice di errore. Il codice di errore deve essere STATUS_IO_TIMEOUT, ma non viene verificato per motivi di compatibilità.
I test funzionali di base e i test di stress vengono eseguiti su due EEPROMs connessi esternamente. I test funzionali avanzati vengono eseguiti su un LPC1768 mbed che esegue firmware personalizzato. 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. L'aggiornamento del firmware mbed è semplice come trascinamento e eliminazione di un file. Il codice sorgente del firmware è disponibile in github. Le istruzioni per preparare l'mbed ed eseguire i test sono disponibili di seguito.
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 | 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
Esecuzione dei test funzionali e di stress di base
Per eseguire i test è necessario disporre dell'hardware seguente:
- Atmel AT24HC serie EEPROMs qt. 2
- 10k resistor qt. 2
- Breadboard
- Cavi
Collegare le EEPROMs come illustrato nel diagramma seguente e connettere SDA e SCL al dispositivo in fase di test.
È ora possibile pianificare i test funzionali e di stress di base da HLK Manager.
Esecuzione dei test funzionali avanzati
I test funzionali avanzati verificano il comportamento di NACKing, le condizioni del bus in sospeso, l'estensione dell'orologio e l'avvio ripetuto. I test richiedono la connessione di un firmware personalizzato LPC1768 mbed al dispositivo in fase di test. Prima di eseguire i test, è necessario caricare il firmware HLK nell'LPC1768 mbed. Ecco come aggiornare il firmware:
- Collegare l'LPC1768 mbed tramite USB al PC. Verrà visualizzata come unità rimossa 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 nel mbed
- Premere il pulsante sul mbed per reimpostare il microcontroller
Successivamente, collegare il mbed al dispositivo in fase di test. Collegare l'mbed tramite USB al dispositivo in fase di test. Quindi, effettuare le connessioni I2C (pinout mbed),
- Connettere mbed pin 9 (P0.0/SDA) al pin SDA nel dispositivo in fase di test
- Connettere mbed pin 10 (P0.1/SCL) al pin SCL nel dispositivo in fase di test
- Connettere mbed GND a un pin GND nel dispositivo in fase di test
Mbed dispone di resistori di pull interni abilitati nelle linee SDA e SCL e non richiede resistori di pull-up esterni.
È ora possibile pianificare i test funzionali avanzati da HLK Manager.
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. 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:I2c*
Utilizzo test della riga di comando:
minte\te windows.devices.lowlevel.unittests.dll [/name:test_name] [/select:select_clause] [/p:I2cFriendlyName=friendly_name] [/p:Duration=duration]
- test_name : il nome del test da eseguire che può includere caratteri jolly. Esempi: /name:I2c*, /name:I2cEepromWriteTests#metadataSet0::VerifyWrite#metadataSet0
- select_clause : clausola di selezione TAEF. Esempio: /select:"@name='I2c*' e not(@name='I2cTestsEx*')"
- friendly_name : nome descrittivo del controller I2C in fase di test. Se omesso, viene usato il primo controller enumerato. Esempi: /p:I2cFriendlyName=I2C0
- durata: quanto tempo eseguire test di stress. Esempi: /p:Duration=10s (10 secondi), /p:Duration=1m (1 minuto), /p:Duration=2h (2 ore), /p:Duration=1d (1 giorno)
Esempi:
Per eseguire i test funzionali di base,
minte\te windows.devices.lowlevel.unittests.dll /select:"@name='I2c*' and not(@name='I2cTestsEx*')"
Per eseguire i test funzionali avanzati,
minte\te windows.devices.lowlevel.unittests.dll /name:I2cTestsEx::*
Per eseguire i test su un'istanza del controller I2C specifica, passare il nome descrittivo al parametro di test I2cFriendlyName,
minte\te windows.devices.lowlevel.unittests.dll /name:I2c* /p:I2cFriendlyName=I2C0
Per eseguire un test specifico, passare il nome completo del test al parametro /name:
minte\te windows.devices.lowlevel.unittests.dll /name:I2cNonexistentSlaveAddressTests::TestWriteRead
Per eseguire i test di stress per la durata consigliata di 8 ore, eseguire
minte\te windows.devices.lowlevel.unittests.dll /name:I2cStressTests::StressIoConcurrent /p:Duration=8h
Uno strumento che può essere utile per la risoluzione dei problemi manuali è I2cTestTool. I2cTestTool è un'utilità semplice per interagire con I2C dalla riga di comando.
Altre informazioni
Parametri
| Nome parametro | Descrizione dei parametri |
|---|---|
| I2cFriendlyName | Nome descrittivo del controller I2C in fase di test (ad esempio I2C0). |