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

Trabajé en un producto que tenía un total de siete MCU. El diseño que hicimos incluyó un bus serie de dos cables implementado como RS485 que se descartó a cada placa MCU y terminó en las líneas TxD y RxD de cada UART de la MCU.

Cada MCU se programó con un cargador de arranque que respondería al tráfico RS485 que podría permitir la reprogramación del FLASH de "código de aplicación" de la MCU. La entrada en el modo de cargador de arranque en el momento del encendido fue controlada por el voltaje analógico en una determinada entrada A / D. En el funcionamiento normal del sistema, el pin leería cerca de GND. Algo entre 2.5 y 4V se vería como un "modo de calibración" mientras que una lectura A / D de más de 4.5V se usó para señalar el modo de cargador de arranque. Las entradas A / D se desviaron a través de un divisor de voltaje, de modo que el voltaje aplicado externamente en el cable CAL / BOOT externamente tenía que ser superior a 20 V para entrar en el modo de cargador de arranque. Este cable de señal analógica también se conectó a las siete MCU.

Una PC externa estaba equipada 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. La misma computadora también se configuró con una utilidad de calibración especializada que usó 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 la misma familia de chips del fabricante, se utilizó 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 electrónica. El código de aplicación del producto se cargó en cada MCU en la prueba de nivel de placa inicial para ahorrar tiempo al tener que hacerlo en la prueba funcional de 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 el 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 pogo pines en un dispositivo de placa que dio acceso a esta interfaz. A través de eso fue posible reprogramar el FLASH completado 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 tarjetas 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. Utilicé esto para programar el MCU a través de una interfaz ICD (depuración en el circuito).

El circuito normalmente estaba deshabilitado (por lo tanto, si alguien enchufaba un cable USB 3.0 real, no se dañaría), pero se habilitó usando un voltaje específico sobre el cable GND_DRAIN (pin 7) de la interfaz USB 3.0 (cables internos GND_DRAIN) no está conectado al pin principal de GND 4).

Al habilitar la interfaz (mediante un comparador) se conmutaron cuatro cables de la interfaz ICD a través de un interruptor analógico cuádruple 4066. El quinto cable (tierra) usó el cable GND normal de la interfaz USB 2.0.

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