Sí, usted puede hacer remota de actualizaciones de firmware con el STM32.
Ahora tienes dos opciones:
- el uso de la STM32 del programado en fábrica del gestor de arranque
- escribir su propio gestor de arranque
Utilizando el programado en fábrica del gestor de arranque requiere arrancar el chip con pin BOOT1 sacó bajo y BOOT0 sacó de alta, y el módulo Bluetooth debe estar conectado a una específica USART periférica (hay otras interfaces, dependiendo del STM32 modelo, pero supongo que el USART tiene más sentido aquí). También, usted necesita para escribir una aplicación de interfaz con el gestor de arranque, después de que el gestor de arranque del protocolo de comandos que está documentado aquí. Para evitar tener que escribir el código para la interfaz del gestor de arranque, puede utilizar el STM32 Cargador de Flash demostrador de aplicación; por supuesto, esto requiere que el otro extremo de la conexión Bluetooth ser conectado a un PC, así que no tiene sentido en cada escenario.
La otra posibilidad es escribir su propio gestor de arranque, que le da más control. Usted puede, por ejemplo, desencadenar el gestor de arranque usando un software de secuencia única, por lo que no es necesario establecer ciertos pines como es requerido por el programa en la fábrica gestor de arranque. Por supuesto, la escritura es un gestor de arranque implica mucho más esfuerzo que el uso de uno que ya está escrito, probado y se entregan con el MCU.
Algunos breves comentarios acerca de la escritura de su propio gestor de arranque. Un bootloader es un trozo de código de firmware como cualquier otro. Se carga en el MCU durante la producción (o depuración) proceso junto con el código principal.
A pesar de ser de código como cualquier otro, ya que el gestor de arranque se utiliza para reprogramar el MCU del firmware, se merece un par de consideraciones especiales. Primero de todos, por su sencillez, puede que desee hacer de su gestor de arranque totalmente separado de la pieza de código desde el código principal. Modificar el gestor de arranque y el código principal del enlazador de secuencias de comandos, de manera que cada uno utiliza una completamente distinta segmento de memoria flash. De esa manera, usted puede actualizar el código principal sin tocar el bootloader. Cuando el gestor de arranque es parte del código principal, si el proceso de actualización se encuentra algún tipo de problema, a continuación, el dispositivo es de ladrillo. Código del gestor de arranque debe ser muy fiable, ya que un error en un gestor de arranque puede ser la diferencia entre que el usuario pueda reparar el dispositivo por sí mismo después de una fallida actualización, frente a está obligado a llevarlo a un centro de servicio. Personalmente, me gustaría hacer el bootloader tan pequeño y simple como sea posible, incluso yendo tan lejos como para evitar el uso de interrupciones, ya que en una manera de hacer que el código sea menos predecible. Por lo general, yo estoy a favor de las interrupciones, pero este es el único caso en el cual estoy en contra del uso de ellos.
Brevemente, un gestor de arranque se carga cuando el dispositivo se inicia, y por lo general sólo las manos el control sobre el código principal. Sin embargo, cuando se realiza una actualización de firmware, a continuación, el gestor de arranque se ejecuta su propio código después del arranque en su lugar. Este código debe incluir algún tipo de comunicación (en su caso) o controlador de almacenamiento, por lo que puede recibir/leer el binario para el código actualizado, a través de Bluetooth, Ethernet, una tarjeta SD, una unidad flash o lo que sea. Luego se borra el código antiguo y reprograma la memoria flash con el nuevo código.
Uno de los trucos que se debe hacer cuando la reprogramación de la memoria flash es la reubicación (copiar) la parte del código del gestor de arranque a la memoria RAM, ya que no se puede ejecutar el código de flash mientras está programado (incluso si la dirección que se está leyendo es diferente de la dirección que se está programando). También, la actualización del código binario que va a ser escrito para flash debe estar en la memoria RAM. Normalmente no habrá suficiente memoria RAM para almacenar el código completo para la actualización, así que no es extraño recibir/leer un bloqueo parcial de código, escribir, recibir/leer otro parcial bloque de código, escribir, y así sucesivamente.
La programación de la memoria flash no es un asunto simple de la escritura de datos en las direcciones deseadas. Hay una programación de flash manual para cada uno de los miembros de la STM32 de la serie (por ejemplo, aquí está el manual para la STM32F10x de la serie). En breve, debido al bajo nivel de los detalles de cómo la memoria flash es implementado, antes de la reprogramación de un bloque dado, deberá emitir un comando borrar. También, usted no puede hacer cualquier lee de flash mientras está siendo programado, así que olvídate de las interrupciones, DMA, etc. a menos que simplemente no hay posibilidad de que ellos van a tratar de lectura de flash mientras está siendo escrito.
