Automatización de las pruebas de interfaz de audio en plataformas integradas

La interfaz de audio se ha vuelto omnipresente hoy en día. Está disponible en la mayoría de las computadoras de placa única (SBC) para la Internet industrial de las cosas (IIOT). Hay varios tipos de interfaces disponibles que van desde puertos de audio analógico hasta puertos de audio digital. Cada tipo de esta interfaz tiene sus propios desafíos en diseño y pruebas. Las pruebas de estas interfaces durante el ensamblaje y la producción involucran la ruta completa desde el extremo frontal analógico o digital hasta los puertos de entrada de audio digital de una unidad de procesamiento.

La interfaz de audio en una plataforma integrada y el flujo genérico de la ruta de datos de audio en un entorno de configuración de prueba de producción se muestran a continuación (Figura 1),

Figura 1:Configuración de prueba y interfaz de audio para una plataforma integrada (fuente:autor)

El diagrama anterior muestra los principales bloques / componentes presentes en la ruta de datos. El IC del receptor presente puede ser un IC de entrada analógica, como un convertidor de analógico a digital (ADC) o también puede ser un IC de receptor de audio digital. La salida del IC puede estar en cualquier formato de serie como Inter-IC Sound Bus (I2S). Esta interfaz puede transportar datos de audio sin procesar en formato de modulación de código de pulso (PCM).

El objetivo de las pruebas de producción es garantizar que la ruta de audio completa se pruebe funcionalmente para todo tipo de problemas. Los posibles problemas pueden incluir lo siguiente:

• Fallo del IC del receptor frontal.

• Problemas relacionados con el ensamblaje en líneas I2S como atascado en alto (conectado al suministro) o atascado en bajo (conectado a tierra) o cortocircuito entre varias líneas de señal.

Esta prueba de interfaz de audio será parte de un sistema de prueba de producción más grande que probará todas las interfaces en una placa integrada.

A continuación se enumera una técnica común utilizada para detectar problemas relacionados con el ensamblaje en las pruebas de interfaz de audio. Para fallas en el circuito integrado del receptor frontal, es necesario utilizar una técnica diferente, pero esas técnicas están más allá del alcance de este documento.

Técnica 1:pruebas subjetivas

Las pruebas subjetivas implican capturar muestras de datos de audio durante unos segundos y compararlas con el audio real que se reproduce mediante la inspección auditiva. El inconveniente de esta técnica es que necesita la intervención humana y requiere mucho tiempo. Por ejemplo, si hay varios canales estéreo, el usuario debe escuchar y confirmar uno tras otro.

Teniendo en cuenta los inconvenientes de la técnica anterior, hemos creado una forma innovadora de probar las señales de la interfaz de audio y automatizar todo el proceso.

Técnica 2:pruebas automatizadas

Para comprender esta técnica de prueba automatizada, es importante comprender algunos conceptos fundamentales de la interfaz I2S.

I2S tiene tres señales:BCLK (bit clock), WCLK (word clock), DATA (señales de datos). Si el BCLK o WCLK no son adecuados (atascados en alto / bajo), el puerto de entrada de audio del procesador no podrá capturar y dará el resultado correspondiente que muestra la falla del reloj. Si estas señales están bien, la captura de audio se producirá independientemente del valor de DATA. Ahora, si DATA está atascado en 1 o 0, entonces el búfer de datos de audio contendrá todos los FFFF o todos los 0000 para cada muestra de 16 bits. Por lo tanto, cuando generamos la suma de comprobación MD5, obtendremos dos valores correspondientes:MD5 (FFFF) y MD5 (0000). Para cualquier otro valor de datos de audio, la suma de comprobación MD5 será diferente. Este concepto se puede utilizar para automatizar y verificar las señales de captura de audio.

El procedimiento para este método es capturar el audio cuando se está reproduciendo el audio adecuado y no está en silencio. Esto asegurará que nuestro archivo de audio solo se capture y que los datos en el búfer sean correctos. Una vez que un búfer de datos de audio ha capturado alrededor de 100 muestras, se puede generar su suma de comprobación MD5. Si la señal de DATOS se atascó en alto, entonces su valor de suma de verificación MD5 será el mismo que MD5 (FFFF) y si se atascó en bajo, entonces su valor de suma de verificación MD5 será el mismo que MD5 (0000). Si la señal de DATOS está alternando, el valor de la suma de comprobación MD5 será cualquier otro valor aleatorio. Por lo tanto, basándonos en el valor de suma de comprobación MD5, podemos llegar a una conclusión sobre si la señal de DATOS tiene algún problema.

Por lo general, estas líneas I2S tendrán múltiples señales de datos. Podemos demostrar esto con el siguiente ejemplo de bus I2S con cuatro señales de datos DATAx (x =0,1,2,3). Esto se puede hacer dando datos de audio en una de las señales de DATOS y 0 para todas las señales de datos restantes. De esta manera, cuando podemos generar la suma de verificación MD5 de los datos capturados de todos los DATAx (x =0,1,2,3) y confirmar que los valores de la suma de verificación MD5 son los esperados.

Si hemos proporcionado datos de audio solo en DATA0, la suma de comprobación MD5 para las señales DATA1-3 debe ser MD5 (0000) y para DATA0 debe ser un valor aleatorio. Esto se puede hacer para las cuatro señales de datos una tras otra en cuatro iteraciones, como se muestra en la Tabla 1.

haz clic para ampliar la imagen

Tabla 1:Iteración de las pruebas de audio (Fuente:Autor)

La limitación de esta técnica es que se puede utilizar para identificar únicamente los problemas descritos anteriormente. Para algunos casos de uso, no puede distinguir entre los problemas. Por ejemplo, si hay varias líneas de señal en cortocircuito, la técnica puede detectar que hay un problema, pero no puede decir claramente qué líneas están en cortocircuito.

Conclusión

Los métodos mencionados anteriormente se han probado y actualmente se utilizan con éxito para probar interfaces de entrada de audio en muchas placas de hardware desarrolladas por Ittiam. Hemos visto que ha reducido el tiempo de prueba general de las interfaces de audio, lo que resulta en un menor costo de prueba de la placa.

Ayusman Mohanty es un arquitecto de productos con un enfoque clave en la construcción de hardware para sistemas de vigilancia y transmisión de video y audio. Se le puede contactar a través de Linkedin.