Automatización de producción de electrónica de señal mixta de bajo volumen (prueba de hardware, calibración, parpadeo) [cerrado]

2

Estoy diseñando una tarjeta de señal mixta con microcontrolador que necesitará programación de memoria flash para su firmware, (auto) pruebas y documentación para los pasos finales de producción.
Sé que hay una rama completa de la industria de fabricación de productos electrónicos solo alrededor de las pruebas (ATE), pero aún no he encontrado una lista simple de pasos y opciones para el proceso básico, solo para comenzar y descubrir la forma más sencilla y económica. De automatizar esto a pequeña escala.

Comencemos con el flasheo esencial del micro:

  1. Conecte el dispositivo al programador (PC + Software)
  2. Haga clic en el botón "programa" para actualizar el firmware
  3. Desconectar dispositivo

¿Cómo se simplificaría esto a una mínima participación humana como

  1. Insertar dispositivo
  2. Eliminar dispositivo

? Probablemente con

  • una plantilla de prueba y sondas con resorte (pogo-pins) para las conexiones.
  • un método para que la computadora detecte el dispositivo (cámbielo o vuelva a intentarlo hasta que se haya establecido la conexión correcta con MCU).
  • una interfaz hombre-máquina (audio, visual a través de PC o en una plantilla de prueba)

La IO de la máquina podría ser tan "simple" como otra placa de microcontrolador (por ejemplo, Arduino) conectada a través del puerto serie (UART / RS-232). Entonces es posible que el software de la PC deba personalizarse para controlar el proceso (software IO y Flasher). Por supuesto, solo para el flasheo hay varias opciones (enlace específico del proveedor, JTAG, cargador de arranque).

Lo siguiente de interés sería la prueba y calibración automatizada del dispositivo. Por supuesto, esto es muy específico para el hardware. El equipamiento necesario podría generalizarse como

  • fuente de alimentación
  • generador de señal (voltaje de referencia / señal)
  • dispositivo de medición (multímetro, osciloscopio)
  • cargas (sumideros, fuentes)
  • interfaces

En lugar de usar rutinas de autoprueba o IO en el hardware (firmware de prueba por separado o rutinas de prueba que forman parte del firmware de producción), las pruebas de bajo nivel pueden ser ejecutadas por un host de control externo a través del hardware Escaneo de límites / JTAG .

Dependiendo del circuito, esto podría simplificarse a autopruebas con una plantilla pasiva que en su mayoría actúa como un dispositivo de bucle invertido.

En cualquier caso, una secuencia general para prueba / calibración podría ser:

  1. aplicar señal
  2. señal de medida
  3. [calcular / almacenar parámetros de calibración]

Por ejemplo, las salidas podrían regresar a (múltiples) entradas a través de la plantilla de prueba. La calibración de señales analógicas requiere una referencia que podría ser externa. La conmutación de la señal podría ser necesaria si se utiliza una referencia con entradas (ADC) y salidas (DAC), por ejemplo.

  1. aplicar voltaje de referencia externo a la entrada
  2. entrada de calibración
  3. cambiar la salida a entrada
  4. salida de autocalibración (ajustar hasta que la salida sea la misma que la referencia)

Alternativamente, se podría usar un comparador externo con el voltaje de referencia para la retroalimentación (que requiere una entrada y una rutina para buscar el valor de salida correcto). Por supuesto, hay equipos de prueba estándar con interfaces de control disponibles que permiten el ajuste / medición directa de señales analógicas para calcular los valores de calibración.

Escribir los datos de calibración en el dispositivo o en la memoria adjunta requiere las estructuras / direcciones de datos correspondientes utilizadas por el firmware. Los datos pueden escribirse directamente en la memoria cuando sea posible (limitaciones de la memoria flash, por ejemplo, ciclo de borrado, tamaño de bloque) o incrustados en la imagen de firmware / eeprom antes de escribir el firmware de producción final. Alternativamente, si el firmware tiene una interfaz de calibración, esto podría usarse para transferir / actualizar estos valores después de parpadear una vez que el dispositivo se esté ejecutando.

En cuanto a la identificación y la documentación, si no hay una identificación de hardware en los dispositivos, el entorno de prueba podría generar una y escribirla en el dispositivo. La información del firmware y del producto podría escribirse en la base de datos y enviarse a la impresora de etiquetas para obtener una identificación física en el dispositivo.

Por supuesto, cualquier solución es siempre una compensación y solo se puede enfocar más en base a los detalles de los requisitos de la prueba.

Me gustaría recibir más ideas o punteros a cuentas de implementaciones.

Ver también:
pregunta handle

1 respuesta

1

muchos programadores ARM libres (utilidad ST-LINK, Jlink, etc.) tienen el modo automático. Usualmente uso la utilidad ST-LINK + pogo pins. Cuando el dispositivo está conectado, la utilidad ST-LINK lo detecta, programa los parpadeos, establece los bits de opción (protección de memoria, por ejemplo) y solicita la desconexión del dispositivo, luego espera otra. Incluso haciéndolo manualmente puedes programar 100-200 dispositivos / hora.

La calibración es más difícil de lo que necesitas tener

  1. Utilidades de calibración en su software, a menudo con la señalización en el pin cuando la calibración está lista.

  2. Software en el lado de la PC: normalmente escribo mis propios programas para él. Así que establece los datos de calibración y espera la confirmación del dispositivo, establece otros y así sucesivamente. El pin de señalización no tiene que estar dedicado, solo lo necesita durante la calibración. Solo se necesita una almohadilla para el pin pogo.

respondido por el P__J__

Lea otras preguntas en las etiquetas