Tests de détection d’écart de transfert SPI WinRT (mbed LPC1768 obligatoire)

Les tests SPI effectuent des tests fonctionnels et des tests 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’écarts entre les octets 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 à moins de 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 LPC1768 mbed connecté en externe. 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 programmation du mbed avec l’image de microprogramme de test consiste à faire 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. Vous trouverez ci-dessous des instructions détaillées sur la préparation du mbed et l’exécution des tests.

Détails du test

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 :

• 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
• Câbles jumper

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 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 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 : (mbed pinout),

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. Connecter 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 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. Nous vous recommandons également de brancher un analyseur logique tel qu’un salae. Il peut être difficile ou impossible de déterminer la cause d’une défaillance sans la possibilité d’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 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:SpiHlk*
   

Utilisation du test 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 en cours de 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=15000000
• 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