Sí, puede hacer actualizaciones de firmware remotas con el STM32.
Ahora tienes dos opciones:
- utilizando el gestor de arranque programado de fábrica del STM32
- escribiendo tu propio gestor de arranque
El uso del cargador de arranque programado de fábrica requiere arrancar el chip con el pin BOOT1 bajado y BOOT0 alto, y el módulo Bluetooth debe estar conectado a un periférico USART específico (hay otras interfaces, dependiendo del modelo STM32 específico, pero Supongo que el USART tiene más sentido aquí). Además, debe escribir una aplicación para interactuar con el cargador de arranque, siguiendo el protocolo de comando del cargador de arranque que está documentado aquí . Para evitar escribir código para interactuar con el gestor de arranque, puede utilizar la aplicación de demostración STM32 Flash Loader ; Por supuesto, esto requiere que el otro extremo de la conexión Bluetooth esté conectado a una PC, por lo que no tiene sentido en todos los escenarios.
La otra posibilidad es escribir tu propio gestor de arranque, lo que te da más control. Por ejemplo, puede activar el cargador de arranque utilizando una secuencia solo de software, de modo que no necesita configurar ciertos pines como lo requiere el cargador de arranque programado de fábrica. Por supuesto, escribir un cargador de arranque de este tipo implica mucho más esfuerzo que usar uno que ya está escrito, probado y enviado con la MCU.
Algunos comentarios breves sobre cómo escribir tu propio gestor de arranque. Un gestor de arranque es una pieza de código de firmware como cualquier otra. Se carga en la MCU durante el proceso de producción (o depuración) junto con el código principal.
A pesar de ser un código como cualquier otro, ya que el cargador de arranque se usa para reprogramar el firmware de la MCU, merece algunas consideraciones especiales. En primer lugar, para simplificar, puede querer que su gestor de arranque sea un fragmento de código completamente separado de su código principal. Edite los scripts de vinculador del bootloader y del código principal, de modo que cada uno use un segmento completamente distinto de memoria flash. De esa manera, puede actualizar el código principal sin tocar el gestor de arranque. Cuando el gestor de arranque es parte del código principal, si el proceso de actualización encuentra algún tipo de problema, entonces su dispositivo está bloqueado. El código del cargador de arranque debe ser muy confiable, ya que un error en un cargador de arranque puede ser la diferencia entre que el usuario pueda reparar el dispositivo por sí mismo después de una actualización fallida, en lugar de verse obligado a llevarlo a un servicio centrar. Personalmente, haría que el gestor de arranque sea lo más pequeño y sencillo posible, incluso para evitar el uso de interrupciones, ya que de alguna manera hacen que el código sea menos predecible. Por lo general, estoy a favor de las interrupciones, pero este es el único caso en el que estoy en contra de usarlas.
Brevemente, se carga un gestor de arranque cuando se inicia el dispositivo, y generalmente solo se le entrega el control al código principal. Sin embargo, al realizar una actualización de firmware, el gestor de arranque ejecuta su propio código después del arranque. Este código debe incluir algún tipo de comunicación (en su caso) o controlador de almacenamiento, para que pueda recibir / leer el binario del código actualizado, a través de Bluetooth, Ethernet, una tarjeta SD, una unidad flash o cualquier otro. Luego borra el código anterior y reprograma la memoria flash con el nuevo código.
Uno de los trucos que se deben realizar al reprogramar la memoria flash es reubicar (copiar) parte del código del cargador de arranque en la RAM, ya que no puede ejecutar el código de Flash mientras está programado (incluso si la dirección se está leyendo es diferente de la dirección que se está programando). Además, el código binario actualizado que se va a escribir en flash también debe estar en la memoria RAM. Por lo general, no habrá suficiente RAM para almacenar el código completo de la actualización, por lo que no es raro recibir / leer un bloque parcial de código, escribirlo, recibir / leer otro bloque parcial de código, escribirlo, etc.
La programación de la memoria flash no es una simple cuestión de escribir datos en las direcciones deseadas. Hay un manual de programación flash para cada miembro de la serie STM32 (por ejemplo, aquí es el manual de la serie STM32F10x). En resumen, debido a los detalles de bajo nivel de cómo se implementa la memoria flash, antes de reprogramar un bloque determinado, deberá emitirle un comando de borrado. Además, no puede realizar ninguna lectura desde el flash mientras se está programando, así que olvídese de las interrupciones, DMA, etc., a menos que no haya ninguna posibilidad de que intenten leer desde el flash mientras se escribe.