Cómo programar varios STM32F en la misma PCB

Trabajo en un rol de administración y solo tengo un conocimiento de electrónica muy limitado (suficiente para hacer proyectos simples de arduino, etc.).

Estamos trabajando en un producto en este momento que tiene 3 STM32F303 y 2 STM32F103 y el procesador principal es un AM5718.

Me preguntaba cómo haría para cargar y actualizar el firmware y el gestor de arranque de cada procesador, incluido el AM5718.

Los 5 STM32 están conectados al AM5718 a través de UART y todos están en la misma PCB.

Me gustaría tener una buena idea de cómo se haría esto después de que se produzca el PCB y el producto esté en el campo.

Obviamente le preguntaría al ingeniero electrónico que trabaja en el proyecto, pero hemos terminado para Navidad.

No debe estar en los EE. UU., porque el jefe aquí simplemente lo llamaría a su casa.... :/
Jaja tienes razón, estoy en el Reino Unido! No es un problema tan importante que justifique llamar a alguien en casa. ¡Principalmente solo para satisfacer mi curiosidad y también es bueno obtener algunos consejos de terceros!
Hola. Si hay una respuesta que lo ayudó a resolver su problema, haga clic en Aceptar en esa respuesta. Gracias.

Respuestas (3)

Si el diseño del hardware se realiza correctamente y suponiendo que se utilice UART para la programación, los pasos serían aproximadamente los siguientes:

  1. La CPU principal reinicia una MCU seleccionada.
  2. Luego, la CPU lleva los pines de arranque requeridos a un estado apropiado y libera el reinicio.
  3. El cargador de arranque MCU se inicia y espera a que ingresen datos en la línea UART adecuada.
  4. La CPU envía los datos binarios a través de la UART y reinicia la MCU cuando termina.
  5. La MCU se ejecuta con un nuevo firmware.

Aquí hay una imagen que muestra la selección del cargador de arranque para las piezas STM32F10xxx:

ingrese la descripción de la imagen aquí

Los mismos pasos se repetirían para cada MCU.

El procesador principal se puede actualizar de muchas maneras, pero generalmente funciona así:

  1. El firmware se descarga en un almacenamiento local (FLASH, RAM, tarjeta SD, etc.)
  2. La CPU se reinicia y el gestor de arranque descubre el código de actualización.
  3. El gestor de arranque de la CPU lee los datos, comprueba que el binario sea válido y programa los sectores FLASH apropiados.
  4. La CPU se reinicia de nuevo y se carga con el nuevo firmware.

Actualizar.

Según su hardware actual, tendría que ejecutar el cargador de arranque saltando a la dirección de memoria adecuada (consulte la página 20 de AN2606 ). No sé mucho sobre esto, pero su diseñador de hardware debería poder resolverlo. Sin embargo, no tener el control de la línea de reinicio es un poco un descuido.

Entonces, ¿eso requeriría más pines que los 2 pines USART o las MCU estarían conectadas a la CPU principal a través de otros pines?
Me arriesgaría a adivinar que necesitaría al menos dos GPIO más. Uno para restablecer la MCU y otro para elegir el modo BOOT.
¿Qué pines serían el modo de reinicio y arranque en las MCU y a qué pines se conectarían en la CPU? He tratado de mirarme a mí mismo, pero no puedo encontrarle sentido. Actualmente, los pines NRST están conectados a la alimentación a través de una resistencia y los pines de arranque están conectados a tierra.
@ProductDesigner dada la conexión actual por resistencia y conexiones directas a tierra, necesitará un rediseño de circuito/PCB para acomodar las señales controladas por lógica, ahora que sabe cómo funciona
NRST se usa para restablecer y BOOT0 y BOOT1 se usan para seleccionar el modo de arranque. En el lado de la CPU se pueden conectar a cualquier GPIO. Según la descripción de su hardware, es posible que deba usar un método diferente para ejecutar el cargador de arranque. Actualizaré mi respuesta.
Entonces, ¿sería beneficioso tener control tanto de los pines de arranque como de los reinicios? ¿O simplemente se reinicia y deja el pin de arranque como está y controla el gestor de arranque? ¿Cuál sería la configuración ideal?
Bueno, realmente depende de usted y de sus ingenieros decidir eso. Si puede activar el cargador de arranque a través del código, entonces puede tener sentido ahorrar algunas señales y esfuerzo de enrutamiento. Por otro lado, el control de hardware es más confiable. Solo imagine que la MCU se bloqueó, ¿cómo la reiniciaría y le diría que ejecute el gestor de arranque?
Ok gracias por todos tus consejos. Desde el punto de vista del hardware, ¿cómo se conectarían los pines, solo una conexión simple o habría resistencias de subida/bajada?
Los STM32 tienen un pull-up interno permanente en la línea de reinicio, así que eso está cubierto. BOOT0 debe tener una resistencia desplegable para un funcionamiento normal.

Sospecho que necesita cargar el firmware AM5718 a través de JTAG, sin embargo, no estoy muy familiarizado con esta familia de CPU.

El STM32 (como muchas otras CPU ARM en estos días) tiene un cargador de arranque ROM incorporado por ST. En algunas series STM32, esto se hace manteniendo alto el pin BOOT0 durante el reinicio. Para iniciar su programa normal, debe mantener el pin bajo. Sin embargo, esto no siempre está convenientemente en la hoja de datos, sino a menudo en el manual del usuario.

El cargador de arranque ST a menudo admite varios protocolos, y UART es uno muy común. Sin embargo, no todos los UART o ubicaciones de pines en el chip STM32 son compatibles, por lo que debe elegir los pines del puerto serie. Este documento es muy útil si puede encontrar la familia adecuada.

El procedimiento que describe Armandas es correcto. Si tiene algunos pines de repuesto en su CPU AM5718, puede automatizar la activación del gestor de arranque de ST a través del software. Esto cuesta algunos pines GPIO en la CPU; en teoría, 1 línea de reinicio adicional por cada CPU agregada. Es posible que también deba considerar cómo se iniciará su placa en esta configuración mientras el AM5718 no se está ejecutando por completo.

Una pequeña advertencia: en algunas partes de STM32, el gestor de arranque de ROM se apaga una vez que habilita la protección contra lectura. Todavía puede acceder al chip a través de JTAG (después de borrar), pero no a través del gestor de arranque. Además, si no puede hacer que la activación automática parezca encajar en el hardware, es posible que deba hacerlo manualmente a través de puentes y un procedimiento en papel. Sin embargo, esto solo es práctico para hacer en la fábrica; no es una solución muy útil en el campo.

Ambas razones pueden guiarlo hacia un gestor de arranque interno que se puede activar a través de un comando en serie. También agrega la ventaja de 'proteger' las imágenes de su firmware a través del cifrado, dado que maneja el descifrado dentro del cargador de arranque.

Ok, por el momento estoy pensando que es mejor tener los STM32 conectados a la CPU principal a través de sus propios UARTS y tener sus pines de arranque y reinicio conectados a los GPIO de la CPU. Todavía no estoy interesado en el software, solo quiero que el diseño del hardware esté preparado para el futuro.

Si todas las partes son compatibles con JTAG y están todas en el mismo dominio de energía (o en un estado que garantice la integridad de la cadena), puede construir una cadena de escaneo y usarla para golpear cada parte por turno.

Sin embargo, parece que el proyecto está terminado y usted está en la administración :), por lo que creo que la opción UART es la mejor ruta. Para ser claros, cada STM tiene su propio UART para el procesador grande, ¿o lo comparten (lo cual es un poco extraño...)? Si es lo último, como dijeron los otros carteles, necesitará un GPIO para seleccionar quién está activo.

La primera etapa del desarrollo de hardware está lista para la creación de prototipos. Solo estaba mirando los esquemas y me preocupaba que los STM solo estén conectados a la CPU principal a través del UART, sus pines de reinicio y arranque están conectados a power/gnd como se indicó anteriormente. Cada STM está conectado a la CPU principal a través de su propio UART. Así que estoy pensando en este momento que la mejor apuesta es tener cada STM conectado a la CPU a través de UART separados (como lo están actualmente) y luego conectar sus pines de arranque y reinicio a los GPIO de la CPU principal.
Sí, eso parece sensato. Lo único que me aseguraría es que su cadena de reinicio se propague a través de la CPU independientemente del estado del software; es decir, cuando VDD cae por debajo del umbral aceptable, un supervisor interno se hará cargo y activará el reinicio, o debe ejecutar el control GPIO para el reinicio de cada STM a través de un supervisor de reinicio IC.
Ok, me has perdido ahora ... Recuerda que no tengo un gran conocimiento sobre el trabajo en electrónica de esta escala. Entonces, ¿está hablando de tener un IC separado para manejar los reinicios? Realmente solo estoy interesado en obtener el hardware correcto en este momento.
Por lo general, se utiliza un supervisor de restablecimiento independiente cuando desea que un elemento de hardware sin estado confirme un restablecimiento en determinadas condiciones. Por ejemplo, un supervisor de restablecimiento de 3,3 V puede ser una parte de 5 pines: VDD, GND, RST, RST# y MR#. Se restablecerá cuando el voltaje llegue a 3,08 V (o lo que sea que esté configurado también, algunos son ajustables) para que todos los procesadores, etc. se restablezcan de manera segura antes de que sus fuentes de alimentación caigan demasiado. El pin MR# es algo que puede conectar para decir un botón; genera un pulso cuando lo afirma y luego lo suelta, o si lo deja presionado, mantendrá todo en reinicio.
¿Creería que es necesario un supervisor de reinicio en esta aplicación? ¿Sería un ic por procesador o solo uno para todo el sistema? ¿Cuál sería un buen ic para usar?
Sin saber más sobre la aplicación, no estoy seguro de si es 100% necesaria, pero en general, si te lo puedes permitir, creo que es una buena idea tener que protegerte contra posibles daños en los datos u otros problemas. Se asegurará de que su sistema esté en un estado de reposo cuando el voltaje caiga demasiado. Podemos hablar más por correo electrónico si desea compartir más detalles sobre su producto en un entorno menos público.