Escribir el software de un fixture de prueba de producción

El fixture de hardware está terminado: los pogo pins caen sobre los puntos de prueba y la placa queda bien asentada. Entonces alguien tiene que decidir qué hace la computadora una vez que la placa está sujeta. Un script de banco que funcionaba para el ingeniero que lo escribió se vuelve un problema cuando lo corre otra persona, una placa falla a la mitad y nadie puede decir qué unidad se probó con qué firmware.

El software del fixture es un pequeño producto en sí mismo. También es más fácil de hacer bien de lo que la gente espera, porque casi todo ya existe como herramientas open source.

Decide qué debe demostrar la prueba

Una prueba funcional no es una repetición de la validación del diseño. Responde una pregunta por placa: ¿esta unidad se construyó correctamente? Eso lleva a una lista corta de verificaciones, la mayoría de las cuales detectan fallas de ensamblaje y no fallas de diseño.

• Alimentación. Los rieles de alimentación suben al voltaje esperado con un consumo de corriente razonable. Un corto o una parte faltante suele verse aquí primero.
• Programación. El firmware se carga y se lee de vuelta idéntico.
• Comunicación. El procesador responde en su puerto serial o USB, así que sabes que el reloj, la línea de reset y la ruta de depuración funcionan.
• Periféricos. Cada sensor, radio, memoria o driver de la placa se ejercita una vez. Un sensor que devuelve su registro de ID por lo menos demostró su conexión al bus.
• Identidad. A la unidad se le asigna un número de serie, y el resultado se guarda asociado a él.

Todo lo de esa lista necesita un punto de prueba, un pin de conector o un gancho en el firmware. Si la placa todavía está en layout, qué puntos de prueba y pads de programación necesita una placa es el lugar para empezar. Agregar un punto cuesta un pad en la placa; omitirlo puede costar rehacer el fixture.

Programa y verifica antes que nada

El orden importa. Programa primero, porque así todas las verificaciones posteriores pueden usar un firmware de prueba que expone la placa al script. Una buena imagen de prueba tiene una interfaz de comandos por UART o USB que permite al script pedir “lee este sensor” o “cambia el estado de este pin” y obtener una respuesta.

No confíes solo en un código de salida exitoso de la programación. El comando program de OpenOCD acepta las opciones preverify y verify, y su comando flash verify_image compara una imagen contra la flash del destino y devuelve aprobado o fallido. pyOCD ofrece una programación de flash similar desde una API de scripting en Python y es compatible con definiciones de dispositivos CMSIS-Pack, lo que ayuda cuando una parte no viene integrada en la herramienta. De cualquier modo, la idea es leer la flash de vuelta y compararla, y tratar una diferencia como una placa fallida, no como motivo de reintento.

La imagen de prueba y la imagen de envío suelen ser distintas. Decide desde temprano si el fixture programa el firmware final después de que pasan las pruebas, o si la imagen de prueba se reemplaza en un segundo paso. Ambas opciones funcionan. El riesgo es una placa que pasa con el firmware de prueba y se envía sin nada, así que el último paso siempre debe ser una verificación de lo que haya en el chip cuando la placa sale del fixture. Cómo se escriben en esa etapa los números de serie y las llaves únicos se explica en aprovisionar números de serie y llaves en la línea de producción.

Usa un test runner, no un script largo

La estructura típica de quien empieza es un solo archivo de Python que corre de arriba a abajo, imprime “OK” y se cae en la primera sorpresa. Funciona el primer día. Deja de ser mantenible la primera vez que agregas una segunda variante de placa o necesitas correr una sola verificación de forma aislada.

pytest ya resuelve la mayor parte de esto. Sus fixtures administran recursos de larga vida, como un puerto serial, una fuente de alimentación o una sonda de depuración, y los limpian incluso cuando una prueba falla. La parametrización permite que una sola función de prueba corra contra cada riel o cada canal con una tabla de límites. La salida de las aserciones muestra el valor medido junto al límite, que es lo que realmente necesita un operador o un ingeniero que lee un reporte de falla. Y el runner es de uso común, así que el siguiente ingeniero ya lo conocerá.

Estructura la suite en el orden en que se hace el bring-up de la placa. Las verificaciones de alimentación van primero y abortan la corrida si fallan, para que el script nunca intente comunicarse con una placa que tiene un riel en corto a tierra. Detenerse en la primera falla en esas verificaciones tempranas protege la placa y los instrumentos. Las verificaciones posteriores pueden correr todas, de modo que un solo reporte liste cada periférico fallido y no solo el primero.

Cómo hablar con los instrumentos

Si el fixture usa instrumentos de banco, como una fuente programable, un multímetro o un osciloscopio, PyVISA controla los dispositivos de medición a través de una sola interfaz, sin importar si se conectan por GPIB, serial, USB o Ethernet. La mayoría de los instrumentos de prueba aceptan comandos de texto, así que una medición es una cadena corta que se envía y un número que se lee de vuelta.

Para muchas placas el fixture no necesita instrumentos de banco en absoluto. El ADC propio de un microcontrolador, leído a través del firmware de prueba, puede verificar los voltajes de los rieles con una tolerancia útil, y unos cuantos relevadores o interruptores analógicos controlados por GPIO pueden enrutar señales. Eso mantiene el fixture pequeño y bajo el costo de cada unidad adicional. Usa instrumentos externos donde la medición necesite ser mejor de lo que puede ofrecer el ADC de la propia placa, por ejemplo cuando verificas la exactitud de un regulador y no solo que esté vivo.

Uses lo que uses, calibra el fixture, no solo la placa. La resistencia de contacto de las puntas, las caídas en los cables y la referencia de la medición desplazan los números. Pon periódicamente en el fixture una placa “golden” conocida y buena y confirma que sigue leyendo los mismos valores. Cuando un límite empieza a derivar en todas las placas a la vez, la causa suele ser el fixture, no la línea. El lado mecánico de ese desgaste se explica en diseñar un fixture de pogo pins que dure.

Haz que el resultado sea rastreable

Un aprobado solo sirve si puedes volver a encontrarlo. Para cada placa, registra al menos:

1. El número de serie o el ID único leído de la placa.
2. La versión del firmware y la versión del script de prueba.
3. Cada valor medido con su límite, no solo aprobado o fallido.
4. Una marca de tiempo, y qué fixture corrió la prueba.

Escribe el registro como un archivo simple, como CSV o JSON, uno por placa. Una base de datos puede venir después. Los archivos simples sobreviven a un cambio de laptop y pueden adjuntarse a un envío, y los clientes que preguntan “¿qué probaron en la unidad 0412?” suelen preguntarlo años después.

Haz que la falla sea imposible de pasar por alto. El operador debe ver un aprobado o un fallido en grande, y una placa fallida debe apartarse físicamente, no dejarse para revisarla más tarde. No le des al script una forma de omitir una verificación sin dejar una marca en el registro. Si un límite está mal, cambia el límite, en control de versiones, con una razón.

Qué sale mal en la práctica

• Límites copiados de la hoja de datos. Un valor típico no es un límite. Define los límites a partir del rango garantizado de la hoja de datos más el error de medición del fixture, y amplíalos solo con una razón.
• Firmware de prueba que se aleja del producto. La imagen de prueba se compila desde el mismo repositorio y la misma etiqueta que el release, o prueba algo que no se envía.
• Sin política de reintentos. Decide de antemano si una falla de contacto recibe un reintento automático. Un ciclo de reintentos ilimitado y silencioso esconde una punta desgastada.
• Pasos que dependen del operador. Si el resultado depende de cómo se asienta la placa, lo que hay que arreglar es la mecánica del fixture, no las instrucciones.

Cómo lo abordamos

Escribimos el plan de pruebas a partir del esquemático y de las notas de bring-up, construimos el fixture y su script juntos, y entregamos el código fuente para que la prueba pueda volver a correrse y modificarse sin nosotros. Si nos envías el esquemático, la interfaz de depuración del firmware y una lista de lo que debe demostrarse en cada unidad, podemos decirte cómo tendría que ser el fixture.