Partager via


Tests de contrainte I2C WinRT IO (EEPROMs requis)

Les tests I2C effectuent des tests fonctionnels et des tests 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() en tant que HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND) et est signalé par I2cDevice::WritePartial/ReadPartial/WriteReadPartial() comme I2cTransferStatus::SlaveAddressNotAcknowledged.
  • Vérification que les API et les pilotes fonctionnent correctement dans des conditions de contrainte. Les tests de contrainte écrivent et lisent à partir de deux EEPROMs simultanément avec des handles d’appareil distincts sur une durée prolongée.

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

  • Vérification que les données sont écrites correctement pour les longueurs de mémoire tampon allant jusqu’à 16384 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 esclave NAK est alors que le master écrit toujours des octets, le pilote termine la demande avec STATUS_SUCCESS et signale le nombre réel d’octets écrits via 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’étirant jusqu’à 500 ms est autorisée et ne provoque pas l’échec du transfert.
  • Vérification que lorsque l’appareil esclave 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 d’une variété de détaillants en ligne, y compris Sparkfun, Digikey et Adafruit. La mise à jour du microprogramme de mbed est aussi simple que glisser-déplacer un fichier. Le code source du microprogramme est disponible sur github. Des instructions sur la préparation du mbed et l’exécution des tests sont fournies ci-dessous.

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) 240
    Catégorie Développement
    Délai d’expiration (en minutes) 10000
    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és peuvent contenir une documentation supplémentaire, notamment des informations sur les prérequis, l’installation et la 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 :

    Branchez 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 un mbed LPC1768 exécutant un microprogramme personnalisé pour être connecté à 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 sous la forme d’un 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 Windows HLK.

    Nous vous recommandons d’exécuter les tests sur la ligne de commande pour obtenir des informations sur les échecs 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 vers 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. Remplacez les répertoires par c:\data

    5. Exécutez les tests :

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

    Utilisation du test 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 en cours de 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, transmettez 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).
    Durée Spécifie la durée d’exécution de chacun des tests de contrainte. par exemple, 30s, 1m, 1h, 1d