Parpadeo independiente de STM32

Estoy desarrollando una herramienta de fijación para probar una PCB personalizada con ST Bluenrg1 (STM32 M0 core + bluetooth).

Esta herramienta de fijación tiene su propia MCU que funciona a 5V.

Me gustaría flashear automáticamente primero antes de probar los pines de la placa, pero estoy buscando la mejor solución para hacer esto sin gastar 600 EURO en un "Flasher ARM" (que permite el flasheo independiente a través del protocolo hand-shake ).

La idea es usar la MCU de la herramienta de prueba para pedirle al Flasher que inicie la carga del firmware y responder a la Herramienta de prueba si se ha hecho correctamente o no.

Estoy revisando opciones con raspberry + OpenODC, raspberry + usb STlinkv2, buscando flashers con modo autónomo... pero me estoy confundiendo un poco con la mejor opción (la mejor opción con un costo relativamente bajo).

¿Qué soluciones utiliza cuando desea programar sus MCU sin computadora?

ACTUALIZADO: estoy usando el protocolo SWD para programarlo con una computadora y un programador STLINKv2. Lo hago a mano, previo a probar las conexiones en la herramienta de fijación de pruebas. Me gustaría incluir este paso de programación en la herramienta Testing fixture y hacerlo lo más simple posible, ya que esto lo harán otras personas en el almacén (la idea es que la herramienta de prueba cargue primero el código y si todo está bien , pruebe las conexiones)

la herramienta de dispositivo de prueba se ve así

cada mcu tiene su(s) propia(s) solución(es), así que usted elige entre ellas. un núcleo cortex-m0 significa que swd ciertamente está disponible y hay varias soluciones de muy bajo costo allí. incluyendo a veces gestores de arranque integrados con sus propios protocolos. Una placa de conexión ftdi con mpsse puede, con el software adecuado, programar cualquiera de estos protocolos que no involucren diferentes niveles de voltaje. y esos se pueden obtener por $ 15 al por menor completo. No hay razón para pagar más que eso para programar/desarrollar en un cortex-m. los stlinks cuestan $10. jlink clona $5 y así sucesivamente.
no existe tal cosa como "mejor", todo es relativo. Lo mejor de mí, lo mejor de él, lo mejor de ella puede no ser lo mejor para ti. Depende de su configuración, que no hay suficiente espacio aquí para que la describa. Lea la hoja de datos/documentación de la pieza en cuestión y elija la opción si solo una o una de las opciones si hay más de una. O use una parte diferente.
Pi gpio a SWD funciona con openocd, puede que no sea eléctricamente robusto, pero los repuestos son baratos. Cualquier sistema Linux integrado normalmente podría albergar un SWD USB, solo asegúrese (con un alcance) de que realmente pueda controlar NRST. No querrá que su herramienta se base solo en una MCU, ya que la otra parte de esto suele ser el mantenimiento de registros.
Su edición solo reitera lo que ya era cierto: las piezas de los componentes son las mismas que la configuración actual de su PC, lo que necesita es encontrar un sistema más pequeño que pueda hacer el trabajo de la PC y darle una interfaz de usuario simple como un pequeño monitor, un botón para empujar, un indicador bueno/malo, generar cualquier etiqueta de número de serie/certificado firmado único/salida general que necesite, etc. Este no es realmente un trabajo de MCU, aunque podría terminar necesitando una MCU como delegado para hacer alguna tarea en particular en nombre de un sistema mayor.

Respuestas (2)

Estás buscando un gestor de arranque. Afortunadamente, la serie Bluenrg viene con un gestor de arranque desarrollado por ST. Puede consultar AN4872 para obtener más detalles.

Del documento

El cargador de arranque BlueNRG-1 y BlueNRG-2 se activa mediante hardware que fuerza DIO7 alto en el reinicio del dispositivo.

Tenga cuidado de que el Bluenrg sea un MCU de 3,3 V (si no recuerdo mal), es posible que necesite cambios de hardware adicionales.

También puede obtener un programador de producción que almacena el código en sí mismo en lugar de necesitar conectarse a una PC, pero $$$
No. Este es un lugar para SWD como se hace en la pregunta, no un cargador de arranque
@ChrisStratton No estoy de acuerdo, la pregunta no es sobre SWD. Según tengo entendido, un cargador de arranque se adapta perfectamente a las necesidades de OP.
Yo diría que un cargador de arranque también se adapta perfectamente. Es factible almacenar toda la aplicación en la memoria de una mcu 'parpadeante', que simplemente la implementa usando el cargador de arranque ST, y verificar el resultado con la opción de suma de comprobación del cargador de arranque. Los gestores de arranque de ST son muy ligeros y bastante sencillos de implementar.
bootloader es el camino a seguir aquí, diablos, es el caso de uso del libro de texto, para programar un dispositivo en el campo. Sí, la solución raspberry pi es divertida, pero una mcu hablando con los cargadores de arranque de otra mcu y enviándole el nuevo firmware a través de uart/spi, etc., es la forma más rápida y limpia en mi opinión.

También estoy haciendo lo mismo, usando una frambuesa (pero PC Linux también funcionará), un clon de st-link v2 y un script bash:

pasar el archivo bin al script, este descarga el firmware a programar desde un servidor, luego:

  1. use st-info para saber si una MCU de destino está conectada, si es así
  2. intente programar (con borrado masivo, si es necesario)
  3. asegurar el dispositivo
  4. use st-info para saber cuándo se desconecta la MCU de destino

Utiliza un zumbador (con oscilador) conectado a raspberry GPIO para emitir alertas de error o notificar la programación exitosa.

El script se puede descargar gratuitamente desde https://docs.creasol.it/progstm32

Lo que no funciona es el reinicio: al final del aseguramiento del dispositivo, el clon st-link v2 envía un reinicio de hardware (a través de NRST) seguido de algunos comandos SWD que no permiten iniciar el firmware (para prueba automática después de la programación) . Esto debería ser un problema del dongle st-link v2.

Si no se necesita "arranque de firmware después de la programación", esta solución funciona muy bien, especialmente porque descarga automáticamente la nueva versión de firmware a programar (muy útil para la fábrica de ensamblaje).

Parpadeo independiente de STM32
RespuestasAquíPolítica de privacidad1y, 0v