WinUsb: écrire sur le tuyau OUT provoque une corruption des données dans le tuyau IN

Question

Ceci est mon premier projet utilisant le pilote et la bibliothèque WinUsb.

Mon ordinateur hôte utilise WINDOWS 10, toutes les mises à jour sont installées. Mon périphérique haute vitesse exploite trois points de terminaison de données: - Point de terminaison de commande OUT: l'ordinateur hôte l'utilise pour envoyer la commande - IN Point de terminaison de réponse: l'ordinateur hôte reçoit une réponse à chaque commande - Point de terminaison de flux IN: le périphérique envoie des données de flux, 1600 octets avec période de 10 millisecondes.

Dans l'application hôte, il y a deux fils pertinents: - fil de commande envoie des commandes à la Command tuyau et reçoit des réponses de tuyau de réponse - fil flux recueille des données à partir de tuyaux flux fonctions non-attente sont utilisées pour tous les tuyaux .

Chaque fil fonctionne parfaitement si un autre fil est suspendu. Toutefois, si deux threads fonctionnent simultanément, les données du flux apparaissent corrompues en des points arbitraires. Plus d'analyse a révélé les faits suivants: - La corruption apparaît comme une séquence contiguë de mauvais octets. La longueur de la mauvaise séquence correspond à peu près à la longueur des commandes et réponses . - Une séquence incorrecte commence à partir d'un point arbitraire non lié aux limites de paquets. - Les octets incorrects peuvent être différents. parfois, ils sont tous des zéros, parfois ils ont l'air d'ordures. - L'analyse du temps suggère que la corruption se produit une fois que la commande est envoyée au tube de commande.

L'effet disparaît si j'implémente la synchronisation entre les threads, de sorte que les opérations de lecture/écriture sont séparées dans le temps. Cependant, cette solution n'est pas acceptable, je veux que deux threads fonctionnent de manière asynchrone. Est-ce que quelqu'un a fait face à un tel effet?

Answer 1

répondre à ma propre question ...

Hans commentaire était correct, le problème a été ancré dans le firmware.

D'autres détails peuvent être intéressants pour les développeurs de firmware de périphérique, en particulier s'ils utilisent la série Atmel Cortex M7 comme je le fais.

Dans cette série, le contrôleur USB inclut une RAM à double accès pour la mise en mémoire tampon des points de terminaison. Le DPRAM est attribué et géré uniquement par le matériel. Le micrologiciel initialise l'allocation en définissant le bit ALLOC dans le registre de contrôle du point de terminaison. Le manuel de l'utilisateur exige que le micrologiciel définisse les bits ALLOC dans l'ordre croissant. Une fois l'historique du projet, j'ai modifié l'adresse du point de terminaison dans le descripteur du point de terminaison, sans réaliser que cette modification viole l'ordre croissant de l'allocation DPRAM. Par conséquent, les tampons de point de terminaison sont apparus chevauchés, ce qui a provoqué une interférence de données décrite dans la question. Après correction du bug, tout fonctionne correctement.