Tests automatisés d'interfaces audio pour SBC embarqués

Les interfaces audio sont désormais incontournables sur les ordinateurs monocarte (SBC) industriels pour l'Internet des objets (IIoT), couvrant options analogiques et numériques. Chaque type d'interface apporte des défis uniques de conception et de test à adresser tout au long de l'assemblage et de la production. L'objectif est de vérifier toute la chaîne de signal — du CI frontal à l'entrée audio numérique du processeur.

La Figure 1 illustre un flux de test de production typique pour un frontal audio embarqué. Le diagramme met en évidence les composants clés comme le CI récepteur (convertisseur analogique-numérique ou récepteur audio numérique), l'interface série (ex. I²S), et le chemin de données PCM alimentant l'unité de traitement.

Figure 1 : Configuration de test & Frontal audio pour plateforme embarquée (Source : Auteur)

Le chemin de données inclut plusieurs blocs critiques. Le CI récepteur peut être un frontal analogique comme un ADC ou un récepteur audio numérique, et sa sortie peut être transmise en tout format série, le plus couramment I²S. Cette interface transporte les données audio PCM brutes.

Les tests de production doivent valider toute la chaîne audio et détecter des problèmes comme :

• Défaillance du CI récepteur frontal.
• Défauts d'assemblage sur lignes I²S (ex. bloqué à l'état haut, bas, ou paires de signaux en court-circuit).

Ces tests sont intégrés dans un système complet vérifiant toutes les interfaces sur une carte embarquée.

Ci-dessous, nous décrivons une technique largement adoptée pour détecter les problèmes liés à l'assemblage. Les méthodes avancées pour les défaillances de CI frontal sont hors de portée.

Technique 1 – Test subjectif

Le test subjectif capture quelques secondes de données audio et repose sur l'inspection humaine pour les comparer à la lecture source. Bien que simple, cette approche requiert une écoute manuelle, est chronophage, et scale mal avec les configurations multi-canaux.

Technique 2 – Test automatisé

Le test automatisé exploite les concepts fondamentaux I²S pour identifier les défauts rapidement et fiablement.

I²S opère avec trois signaux : BCLK (horloge bit), WCLK (horloge mot), et DATA. Si BCLK ou WCLK est bloqué, le processeur signalera une défaillance d'horloge. Même si les horloges sont correctes, une ligne DATA bloquée à l'état haut ou bas remplira le tampon audio avec 0xFFFF ou 0x0000 pour chaque échantillon 16 bits. En générant un checksum MD5 d'un tampon capturé, nous pouvons distinguer ces cas :

• MD5(FFFF) indique une ligne DATA bloquée à l'état haut.
• MD5(0000) indique une ligne DATA bloquée à l'état bas.
• Tout autre checksum implique un flux de données correct.

Le flux de test est le suivant :

1. Lire un audio connu à travers la carte (s'assurer qu'il n'est pas muet).
2. Capturer environ 100 échantillons.
3. Calculer le checksum MD5 du tampon capturé.
4. Comparer le checksum aux deux valeurs de référence pour détecter les lignes bloquées.

Pour les bus I²S multi-lignes, nous pouvons vérifier chaque ligne DATA indépendamment. Par exemple, avec un bus à quatre lignes (DATA0–DATA3), nous jouons l'audio sur une seule ligne à la fois en forçant les autres à l'état bas. Le checksum MD5 pour la ligne active sera aléatoire, tandis que les lignes inactives correspondront à MD5(0000). Le Tableau 1 démontre cette approche itérative.

cliquer pour agrandir l'image

Tableau 1 : Itération des tests audio (Source : Auteur)

Des limites existent : cette méthode signale la présence d'un problème mais ne localise pas quelles lignes sont en court-circuit ensemble. Néanmoins, elle est très efficace pour détecter les conditions bloquées et courts-circuits simples.

Conclusion

Ces techniques automatisées ont été validées sur de nombreuses cartes matérielles Ittiam, réduisant constamment le temps de test et les coûts de production.

---

Ayusman Mohanty est architecte produit focalisé sur le matériel pour systèmes vidéo/audio broadcast et surveillance. Connectez-vous sur LinkedIn.