Automatiseren van het testen van audio-interfaces op embedded platforms

De audio-interface is tegenwoordig alomtegenwoordig. Het is beschikbaar op de meeste single board computers (SBC's) voor het industriële Internet of Things (IIOT). Er zijn meerdere soorten interfaces beschikbaar, variërend van analoge audio tot digitale audiopoorten. Elk type van deze interface heeft zijn eigen uitdagingen in ontwerp en testen. Het testen van deze interfaces tijdens assemblage en productie omvat het volledige pad van analoge of digitale front-end naar de digitale audio-ingangspoorten van een verwerkingseenheid.

De audio-front-end op een ingebed platform en generieke stroom van audiogegevenspad in een productie-testopstellingsomgeving wordt hieronder weergegeven (Figuur 1),

Figuur 1:Testopstelling &Audio Front-end voor een Embedded Platform (Bron:Auteur)

Het bovenstaande diagram toont de belangrijkste blokken/componenten die aanwezig zijn in het gegevenspad. Het aanwezige ontvanger-IC kan een analoog front-end-IC zijn, zoals een analoog-naar-digitaalomzetter (ADC) of kan ook een digitaal audio-ontvanger-IC zijn. De uitvoer van de IC kan in elk serieel formaat zijn, zoals Inter-IC Sound Bus (I2S). Deze interface kan onbewerkte audiogegevens in pulscodemodulatie (PCM)-indeling dragen.

Het doel van de productietesten is ervoor te zorgen dat het volledige audiopad functioneel wordt getest op allerlei problemen. De mogelijke problemen kunnen de volgende zijn:

• Front-end ontvanger IC-fout.

• Assemblagegerelateerde problemen op I2S-lijnen zoals vastzitten bij hoog (aangesloten op voeding) of vastzitten bij laag (aangesloten op aarde) of kortsluiting tussen meerdere signaallijnen.

Deze audio-interfacetest zal deel uitmaken van een groter productietestsysteem dat alle interfaces op een embedded board zal testen.

Hieronder staat een veelgebruikte techniek die wordt gebruikt voor het detecteren van montagegerelateerde problemen bij het testen van audio-interfaces. Voor een storing in de front-end-ontvanger-IC moet een andere techniek worden gebruikt, maar die technieken vallen buiten het bestek van dit document.

Techniek 1 – Subjectief testen

Subjectief testen omvat het vastleggen van audiogegevensmonsters gedurende enkele seconden en deze te vergelijken met de daadwerkelijke audio die wordt afgespeeld door gehoorinspectie. Het nadeel van deze techniek is dat het menselijk ingrijpen vereist en tijdrovend is. Als er bijvoorbeeld meerdere stereokanalen zijn, moet de gebruiker de een na de ander luisteren en bevestigen.

Gezien de nadelen van de bovenstaande techniek, hebben we een innovatieve manier bedacht om de audio-interfacesignalen te testen en het hele proces te automatiseren.

Techniek 2 – Geautomatiseerd testen

Om deze geautomatiseerde testtechniek te begrijpen, is het belangrijk om enkele fundamentele concepten van de I2S-interface te begrijpen.

I2S heeft drie signalen:BCLK (bitklok), WCLK (woordklok), DATA (gegevenssignalen). Als de BCLK of WCLK niet juist zijn (vastgelopen op hoog/laag), kan de audio-invoerpoort van de processor niet vastleggen en een overeenkomstig resultaat geven dat een klokstoring aangeeft. Als deze signalen in orde zijn, vindt audio-opname plaats, ongeacht de waarde van DATA. Als DATA nu vastzit op 1 of 0, dan bevat de audiodatabuffer alle FFFF of alle 0000 voor elke 16-bits sample. Dus wanneer we de MD5-controlesom genereren, krijgen we twee overeenkomstige waarden:MD5(FFFF) en MD5(0000). Voor elke andere waarde van audiogegevens is de MD5-controlesom anders. Dit concept kan worden gebruikt om de audio-opnamesignalen te automatiseren en te controleren.

De procedure voor deze methode is om de audio vast te leggen wanneer de juiste audio wordt afgespeeld en niet in mute-toestand is. Dit zorgt ervoor dat ons audiobestand alleen wordt vastgelegd en dat de gegevens in de buffer correct zijn. Zodra een audiodatabuffer ongeveer 100 samples heeft vastgelegd, kan de MD5-controlesom worden gegenereerd. Als het DATA-signaal hoog bleef, is de MD5-controlesomwaarde hetzelfde als MD5(FFFF) en als het laag bleef, is de MD5-controlesomwaarde hetzelfde als MD5(0000). Als het DATA-signaal wisselt, is de MD5-controlesomwaarde een willekeurige andere waarde. Daarom kunnen we op basis van de MD5-controlesomwaarde tot een conclusie komen of het DATA-signaal problemen heeft.

Gewoonlijk zullen deze I2S-lijnen meerdere datasignalen hebben. We kunnen dit aantonen met het volgende voorbeeld van een I2S-bus met vier datasignalen DATAx (x =0,1,2,3). Dit kan door audiodata te geven op een van de DATA-signalen en 0 voor alle overige datasignalen. Op deze manier kunnen we een MD5-controlesom van vastgelegde gegevens van alle DATAx (x =0,1,2,3) genereren en bevestigen dat de MD5-controlesomwaarden zijn zoals verwacht.

Als we alleen audiogegevens op DATA0 hebben gegeven, moet de MD5-controlesom voor DATA1-3-signalen MD5(0000) zijn en voor DATA0 een willekeurige waarde. Dit kan worden gedaan voor alle vier de datasignalen, de een na de ander in vier iteraties, zoals weergegeven in Tabel 1.

klik voor grotere afbeelding

Tabel 1:Iteratie van audiotests (bron:auteur)

De beperking van deze techniek is dat deze kan worden gebruikt om alleen de hierboven beschreven problemen te identificeren. Voor sommige gebruikssituaties kan het geen onderscheid maken tussen de problemen. Als bijvoorbeeld meerdere signaallijnen zijn kortgesloten, kan de techniek detecteren dat er een probleem is, maar kan niet duidelijk worden aangegeven welke lijnen samen zijn kortgesloten.

Conclusie

De bovengenoemde methoden zijn getest en worden momenteel met succes gebruikt om audio-invoerinterfaces te testen op veel hardwareborden die door Ittiam zijn ontwikkeld. We hebben gezien dat het de algehele testtijd van audio-interfaces heeft verkort, wat resulteert in lagere testkosten voor het bord.

Ayusman Mohanty is een productarchitect met een focus op het bouwen van hardware voor video- en audio-uitzendingen en bewakingssystemen. Hij is te bereiken via Linkedin.