Partager via


Tests de lecture WinRT I2C (EEPROM obligatoire)

Les tests I2C effectuent des tests fonctionnels et de contrainte des contrôleurs I2C exposés au mode utilisateur via les API WinRT Windows.Devices.I2c. Les tests sont divisés en deux parties : les tests fonctionnels de base et les tests de contrainte, et les tests fonctionnels avancés. L’étendue des tests fonctionnels de base comprend :

  • Vérification qu’un contrôleur I2C avec le nom convivial spécifié est accessible à partir du mode utilisateur.
  • Vérification que les données sont écrites correctement sur une plage de vitesses d’horloge et de longueurs de mémoire tampon allant jusqu’à 8 octets (taille de page EEPROM).
  • Vérification que les données sont lues correctement sur une plage de vitesses d’horloge et de longueurs de mémoire tampon.
  • Vérification que les séquences écriture-redémarrage-lecture (WriteRead) sont exécutées correctement sur une plage de vitesses d’horloge et de longueurs de mémoire tampon.
  • Vérification que lorsqu’une tentative d’écriture, de lecture ou d’écriture est effectuée sur une adresse esclave qui n’est pas reconnue, le pilote retourne STATUS_NO_SUCH_DEVICE. Cela est signalé par I2cDevice::Write/Read/WriteRead() comme HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND) et est signalé par I2cDevice::WritePartial/ReadPartial/WriteReadPartial() en tant que I2cTransferStatus::SlaveAddressNotAcknowledged.
  • Vérification que les API et les pilotes fonctionnent correctement dans des conditions de contrainte. Les tests de contraintes écrivent et lisent simultanément à partir de deux EEPROM avec des handles d’appareil distincts sur une durée prolongée.

L’étendue des tests fonctionnels avancés comprend :

  • Vérification que les données sont écrites correctement pour des longueurs de mémoire tampon allant jusqu’à 16 384 octets.
  • Vérification qu’une condition de redémarrage I2C est générée en réponse à une séquence WriteRead.
  • Vérification que lorsque l’appareil subordonné est NAK alors que le master écrit toujours des octets, le pilote termine la requête avec STATUS_SUCCESS et signale le nombre réel d’octets écrits dans les informations de la demande. Ce transfert est appelé transfert partiel et est signalé par WritePartial() et WriteReadPartial() en tant que I2cTransferStatus::P artialTransfer.
  • Vérification que l’horloge s’étendant jusqu’à 500 ms est autorisée et ne provoque pas l’échec du transfert.
  • Vérification que lorsque l’appareil subordonné maintient la ligne d’horloge basse pendant une durée prolongée (10+ secondes), le pilote termine le transfert dans un délai maximum de 10 secondes avec un code d’échec. Le code d’échec doit être STATUS_IO_TIMEOUT, mais cela n’est pas vérifié pour des raisons de compatibilité.

Les tests fonctionnels de base et les tests de contrainte s’exécutent sur deux EEPROM connectés en externe. Les tests fonctionnels avancés s’exécutent sur un LPC1768 mbed exécutant un microprogramme personnalisé. Le mbed LPC1768 est une plateforme de prototypage de microcontrôleur populaire qui peut être achetée auprès de divers détaillants en ligne, notamment Sparkfun, Digikey et Adafruit. La mise à jour du microprogramme de mbed est aussi simple que de glisser-déplacer un fichier. Le code source du microprogramme est disponible sur github. Vous trouverez ci-dessous des instructions sur la préparation du mbed et l’exécution des tests.

Détails du test

   
Spécifications
  • Device.BusController.I2C.WinRT.Discretional
Plateformes
    Versions prises en charge
    • Windows 10
    • Windows 10, version 1511
    • Windows 10, version 1607
    • Windows 10 version 1703
    • Windows 10, version 1709
    • Windows 10 version 1803
    • Windows 10, version 1809
    • Windows 10 version 1903
    • Prochaine mise à jour de Windows 10
    Durée d’exécution attendue (en minutes) 5
    Catégorie Développement
    Délai d’expiration (en minutes) 10
    Nécessite un redémarrage false
    Nécessite une configuration spéciale true
    Type automatique

     

    Documentation supplémentaire

    Les tests de cette zone de fonctionnalité peuvent avoir une documentation supplémentaire, y compris les conditions préalables, l’installation et les informations de résolution des problèmes, que vous trouverez dans les rubriques suivantes :

    Exécution du test

    Exécution des tests fonctionnels et de contraintes de base

    Vous aurez besoin du matériel suivant pour exécuter les tests :

    Connectez les EEPROMs comme illustré dans le diagramme suivant et connectez SDA et SCL à votre appareil en cours de test.

    Schéma i2c eeprom

    Vous pouvez maintenant planifier les tests fonctionnels et de stress de base à partir du gestionnaire HLK.

    Exécution des tests fonctionnels avancés

    Les tests fonctionnels avancés vérifient le comportement de NACKing, les conditions de bus suspendus, l’étirement de l’horloge et les démarrages répétés. Les tests nécessitent la connexion d’un microprogramme personnalisé mbed LPC1768 à l’appareil testé. Avant d’exécuter les tests, vous devez charger le microprogramme HLK sur le mbed LPC1768. Voici comment mettre à jour le microprogramme :

    1. Branchez le mbed LPC1768 via USB à votre PC. Il s’affiche en tant que lecteur amovible sur votre PC.
    2. Ouvrir le lecteur dans l’Explorateur de fichiers
    3. Copiez c:\Program Files (x86)\Windows Kits\10\Hardware Lab Kit\Tests\x86\iot\busses-tester-mbed_LPC1768.bin dans le mbed
    4. Appuyez sur le bouton du mbed pour réinitialiser le microcontrôleur

    Ensuite, reliez le mbed à votre appareil en cours de test. Branchez le mbed via USB à votre appareil en cours de test. Ensuite, effectuez les connexions I2C (pinout mbed),

    1. Connecter la broche mbed 9 (P0.0/SDA) à la broche SDA sur votre appareil en cours de test
    2. Connecter la broche mbed 10 (P0.1/SCL) à la broche SCL sur votre appareil en cours de test
    3. Connecter mbed GND à une broche GND sur votre appareil en cours de test

    Le mbed a des résistances pull-up internes activées sur les lignes SDA et SCL et ne nécessite pas de résistances pull-up externes.

    Vous pouvez maintenant planifier les tests fonctionnels avancés à partir du gestionnaire HLK.

    Dépannage

    Pour la résolution des problèmes génériques des échecs de test HLK, consultez Résolution des échecs de test HLK Windows.

    Nous vous recommandons d’exécuter les tests sur la ligne de commande pour obtenir des insights sur les défaillances et pour itérer rapidement sur les solutions. Voici comment exécuter les tests sur la ligne de commande :

    1. Copiez %programfiles(x86)%\Windows Kits\10\Testing\Runtimes\TAEF\<arch>\MinTe dans c:\data\minte

    2. Copiez Windows.Devices.LowLevel.UnitTests.dll de %programfiles(x86)%\Windows Kits\10\Hardware Lab Kit\Tests\<arch>\iot vers c:\data sur votre appareil.

    3. Telnet ou ssh dans votre appareil

    4. Remplacer les répertoires par c:\data

    5. Exécutez les tests :

      minte\te windows.devices.lowlevel.unittests.dll /name:I2c*
      

    Utilisation des tests de ligne de commande :

    minte\te windows.devices.lowlevel.unittests.dll [/name:test_name] [/select:select_clause] [/p:I2cFriendlyName=friendly_name] [/p:Duration=duration]
    
    • test_name : nom du test à exécuter, qui peut inclure des caractères génériques. Exemples : /name:I2c*, /name:I2cEepromWriteTests#metadataSet0::VerifyWrite#metadataSet0
    • select_clause : clause de sélection TAEF. Exemple : /select:"@name='I2c*' and not(@name='I2cTestsEx*') »
    • friendly_name : nom convivial du contrôleur I2C testé. En cas d’omission, le premier contrôleur énuméré est utilisé. Exemples : /p:I2cFriendlyName=I2C0
    • duration : durée d’exécution des tests de contrainte. Exemples : /p:Duration=10s (10 secondes), /p:Duration=1m (1 minute), /p:Duration=2h (2 heures), /p:Duration=1d (1 jour)

    Exemples :

    Pour exécuter les tests fonctionnels de base,

    minte\te windows.devices.lowlevel.unittests.dll /select:"@name='I2c*' and not(@name='I2cTestsEx*')"
    

    Pour exécuter les tests fonctionnels avancés,

    minte\te windows.devices.lowlevel.unittests.dll /name:I2cTestsEx::*
    

    Pour exécuter les tests sur un contrôleur I2C spécifique instance, passez le nom convivial au paramètre de test I2cFriendlyName,

    minte\te windows.devices.lowlevel.unittests.dll /name:I2c* /p:I2cFriendlyName=I2C0
    

    Pour exécuter un test spécifique, transmettez le nom complet du test au paramètre /name :

    minte\te windows.devices.lowlevel.unittests.dll /name:I2cNonexistentSlaveAddressTests::TestWriteRead
    

    Pour exécuter les tests de contrainte pendant la durée recommandée de 8 heures, exécutez

    minte\te windows.devices.lowlevel.unittests.dll /name:I2cStressTests::StressIoConcurrent /p:Duration=8h
    

    I2cTestTool est un outil qui peut vous aider à résoudre les problèmes manuels. I2cTestTool est un utilitaire simple permettant d’interagir avec I2C à partir de la ligne de commande.

    Plus d’informations

    Paramètres

    Nom du paramètre Description des paramètres
    I2cFriendlyName Nom convivial du contrôleur I2C testé (par exemple, I2C0).