Tests de vérification spi WinRT Stride

Les tests SPI effectuent des tests fonctionnels et de contrainte des contrôleurs SPI exposés au mode utilisateur via les API WinRT Windows.Devices.Spi. L’étendue des tests comprend les éléments suivants :

• Vérification qu’un contrôleur SPI avec le nom convivial spécifié est accessible à partir du mode utilisateur.
• Vérification que les données sont envoyées et reçues correctement sur une plage de modes SPI, de fréquences d’horloge, de longueurs de bits de données et de longueurs de transfert.
• Vérification qu’il n’y a pas d’écart entre les octets au sein d’un transfert. Certains appareils tels que les bandes LED et les convertisseurs analogique-numérique nécessitent un signal d’horloge ininterrompu.
• Vérification que la vitesse d’horloge réelle utilisée est comprise dans 15 % de la valeur demandée.
• Vérification que lorsqu’un transfert est tenté avec une longueur de mémoire tampon qui n’est pas un multiple de la foulée, le transfert échoue avec STATUS_INVALID_PARAMETER et aucune activité n’est générée sur le bus. La foulée est déterminée par DataBitLength comme suit :

Les tests s’exécutent sur un mbed LPC1768 connecté en externe. 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 programmation du mbed avec l’image de microprogramme de test consiste à glisser-déplacer l’image du microprogramme vers le périphérique de stockage de masse. Le code source du microprogramme est disponible sur github. Des instructions détaillées sur la préparation du mbed et l’exécution des tests sont fournies ci-dessous.

Détails du test

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 :

• Documentation supplémentaire device.BusController

Exécution du test

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

• mbed LPC1768
• Platine d’expérimentation
• Fils de saut

Tout d’abord, vous devez charger le microprogramme de test sur le mbed :

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 sur le lecteur
4. Appuyez sur le bouton du mbed pour réinitialiser le microcontrôleur

Ensuite, reliez le mbed à votre contrôleur SPI en cours de test. Pour alimenter le mbed, vous pouvez le brancher via USB à votre appareil en cours de test ou connecter les broches VIN et GND directement aux broches d’alimentation de votre appareil en cours de test. Établir les connexions suivantes entre votre appareil en cours de test et le mbed : (broche mbed),

1. Connecter la broche mbed 13 (P0.15/SCK0) à la broche SCK sur votre appareil en cours de test
2. Connectez la broche mbed 30 (P0.4/CAP2.0) à la broche SCK de votre appareil en cours de test (cette broche est utilisée pour la mesure précise de l’horloge)
3. Connecter la broche mbed 11 (P0.18/MOSI0) à la broche MOSI sur votre appareil en cours de test
4. Connecter la broche mbed 12 (P0.17/MISO0) à la broche MISO sur votre appareil en cours de test
5. Connectez la broche mbed 14 (P0.16/SSEL0) à l’épingle Chip Select sur votre appareil en cours de test
6. Connecter mbed GND à une broche GND sur votre appareil en cours de test

Vous pouvez maintenant planifier les tests dans HLK Studio.

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. Nous vous recommandons également de raccorder un analyseur logique tel qu’un salae. Il peut être difficile, voire impossible, de déterminer la cause d’une défaillance sans pouvoir inspecter le trafic des bus.

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:SpiHlk*
   

Utilisation des tests de ligne de commande :

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 : nom du test à exécuter, qui peut inclure des caractères génériques. Exemples : /name:SpiHlk*, /name:SpiHlkTests::VerifyClockFrequency#metadataSet0
• friendly_name : nom convivial du contrôleur SPI testé. En cas d’omission, le premier contrôleur énuméré est utilisé. Exemples : /p:SpiFriendlyName=SPI1
• clock_frequency : forcez un test à utiliser la fréquence d’horloge spécifiée. Par défaut, la fréquence d’horloge provient des données de test, qui sont conçues pour fournir une couverture sur une plage de fréquences. Ce paramètre doit être omis dans des circonstances normales. Exemple : /p:ClockFrequency=1500000
• data_bit_length : forcez un test à utiliser la longueur de bits de données spécifiée. Exemple : /p:DataBitLength=9
• SpiMode : forcez un test à utiliser le mode SPI spécifié. Exemple : /p:SpiMode=2
• length : force un test à utiliser la longueur de mémoire tampon spécifiée pour le transfert. Exemple : /p:length=128
• write_length : forcez un test TransferSequential à utiliser la longueur de mémoire tampon spécifiée pour la partie d’écriture du transfert. Exemple : /p:WriteLength=8
• read_length : forcez un test TransferSequential à utiliser la longueur de mémoire tampon spécifiée pour la partie lecture du transfert. Exemple : /p:ReadLength=16
• extra_clocks : spécifiez un ajustement au nombre d’horloges par octet que les tests utilisent lors du calcul des heures d’activité d’horloge attendues pour les mesures de performances, la détection des écarts et la validation de la fréquence d’horloge. Par exemple, le contrôleur SPI BCM2836 attend un cycle d’horloge supplémentaire après chaque octet, de sorte que pour compenser ce comportement, les mesures doivent être ajustées. Exemple : /p:ExtraClocks=1.5
• /p:Verbose=true : activez la sortie détaillée. Cela entraîne le vidage de mémoires tampons entières dans la console en cas de défaillance. Par défaut, seul le premier octet incompatible s’affiche.

Exemples :

Répertorier les tests disponibles :

minte\te windows.devices.lowlevel.unittests.dll /list

Exécutez les tests de validation d’E/S :

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

Exécutez les tests de détection d’écart :

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

Exécutez la validation de la fréquence d’horloge et les tests stride :

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

Exécutez un test spécifique sur un contrôleur SPI spécifique instance :

minte\te windows.devices.lowlevel.unittests.dll /name:SpiHlkIoTests#2::VerifyTransferSequential#metadataSet9 /p:SpiFriendlyName=SPI1

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

Plus d’informations

Paramètres