¿Cómo se cargan el gestor de arranque y el firmware durante la producción? [cerrado]

Si hubiera un producto con 5 MCU (STM32303) y una CPU principal AM5718, ¿cómo se cargaría el gestor de arranque en cada chip?

La misma pregunta sobre el firmware, ¿cómo se cargaría el firmware en cada uno?

¿Se haría antes de soldar los chips, habría almohadillas en la PCB para las sondas o algo más?

Sólo estoy interesado en lo que sucedería en la producción. Cualquier actualización y carga en el futuro ocurrirá a través de la CPU principal a través de UART

Todo lo anterior. Esto está peligrosamente cerca de una pregunta duplicada....
Hay servicios de fabricación por contrato que pueden realizar la programación de dispositivos en un lote de chips antes de montarlos a bordo. Se vuelve un poco complicado porque cada chip debe tener una etiqueta con el número de versión, y debe haber CRC o una suma de verificación similar para verificar la imagen de firmware correcta. Si el firmware todavía está en desarrollo o es posible que deba actualizarse, y hay espacio disponible, es una buena idea incluir programación/depuración en circuito, JTAG o lo que admita el dispositivo.
Mi otra pregunta estaba relacionada con la carga y actualización después de la producción como cuando está en servicio. Me interesa saber cómo se haría esto en producción.
¿No es el bootloader inherente al STM32?
He editado ambas preguntas, mi pregunta anterior está relacionada con la carga y actualización del firmware cuando el producto está en el campo.

Respuestas (2)

Trabajé en un producto que tenía un total de siete MCU. El diseño que hicimos incluía un bus serial de dos hilos implementado como RS485 que se conectaba a cada placa MCU y terminaba en las líneas TxD y RxD de cada uno de los UART de la MCU.

Cada MCU se programó con un cargador de arranque que respondería al tráfico RS485 que podría admitir la reprogramación del "código de aplicación" FLASH de la MCU. La entrada en el modo de cargador de arranque en el encendido fue controlada por el voltaje analógico en una determinada entrada A/D. Bajo la operación normal del sistema, el pin se leería cerca de GND. Algo entre 2,5 y 4 V se vería como un "modo de calibración", mientras que una lectura A/D superior a 4,5 V se utilizó para indicar el modo de cargador de arranque. Las entradas A/D se polarizaron a través de un divisor de voltaje para que el voltaje aplicado externamente en el cable CAL/BOOT externamente tuviera que ser superior a 20 V para entrar en el modo cargador de arranque. Este cable de señal analógica también se envió a los siete MCU.

Se equipó una PC externa con una utilidad de actualización de firmware especial que podía controlar la señal CAL/BOOT y luego interactuar secuencialmente con cada MCU a través del enlace de comunicación RS485 para realizar las actualizaciones de software. Esa misma computadora también se configuró con una utilidad de calibración especial que utilizó el mismo enlace de comunicación RS485 para realizar la calibración y el registro de datos de rendimiento para el producto.

Tenga en cuenta que, dado que todas las MCU eran de la misma familia de chips del fabricante, se usó exactamente el mismo código de cargador de arranque en todas las MCU. Los MCU fueron precargados con los cargadores de arranque por un servicio de programación en el distribuidor de productos electrónicos. El código de la aplicación del producto se cargó en cada MCU en la prueba inicial a nivel de placa para ahorrar tiempo en lugar de tener que hacerlo en la prueba funcional a nivel de producto. Cualquier actualización posterior se realizó en el paquete de nivel de producto sin tener que abrir nada.

Un último comentario es que cada MCU en esta familia de controladores podría programarse en circuito a través de una interfaz de tipo SPI. Proporcionamos almohadillas en cada placa de circuito a las que se podía acceder a través de pines pogo en un dispositivo de placa que daba acceso a esta interfaz. A través de eso, fue posible reprogramar el FLASH completo de la MCU, incluido su cargador de arranque. Una vez que las siete MCU estaban en su lugar en el producto completo, este modo de acceso ya no estaba disponible porque todas las placas electrónicas estaban encapsuladas.

En un proyecto en el que trabajé hace aproximadamente un año, la MCU era un host USB 2.0 y, por lo tanto, había un conector USB en la placa para conectarlo a dispositivos periféricos. Aunque el procesador estaba limitado a USB 2.0, diseñé un conector USB 3.0 que tiene cinco cables adicionales. Usé esto para programar la MCU a través de una interfaz ICD (depuración en circuito).

El circuito normalmente estaba deshabilitado (por lo que si alguien enchufaba un cable USB 3.0 real, no habría ningún daño), pero se habilitaba usando un voltaje específico sobre el cable GND_DRAIN (pin 7) de la interfaz USB 3.0 (los cables internos GND_DRAIN no están conectados al pin principal GND 4).

Habilitar la interfaz (usando un comparador) cambió cuatro cables de la interfaz ICD a través de un interruptor analógico cuádruple 4066. El quinto cable (tierra) usaba el cable GND normal de la interfaz USB 2.0.

La programación se realizó en la fábrica en China utilizando accesorios de prueba especiales que diseñé y que también se usaron para realizar pruebas a nivel de placa. Posteriormente, la placa aún podría reprogramarse a través del mismo conector. Después de que las unidades estuvieran en el campo, dado que tenían un módem GSM en ellas, podían actualizarse usando FOTA (firmware por aire).