Actualizar la aplicación de usuario usando un cargador de arranque personalizado a través de UART (STM32)

Sí. Obviamente puedes enviar múltiples paquetes.

Hay una compensación entre la eficiencia y el costo de obtener un paquete incorrecto. Con paquetes pequeños, hay más sobrecarga total por la cantidad de datos realmente entregados. Sin embargo, si hay un error, será necesario volver a enviar menos datos.

Todo lo dicho, los errores de datos son, o al menos deberían ser, raros. En general, usted envía paquetes de tamaño máximo hasta que queda menos de un paquete completo de datos.

Su algoritmo de suma de comprobación es más bien una broma, digamos "primitivo" en el mejor de los casos. Los paquetes más pequeños tienen más protección de suma de control porque efectivamente hay más bits de suma de control por bit de datos.

Por supuesto que no estás atascado con este gestor de arranque. Puedes escribir uno que haga lo que quieras. Consulte esta pregunta para obtener más información sobre los cargadores de arranque en general.

Más sobre la verificación

Como señaló Peter en un comentario, la corrección de los datos es esencial en un cargador de arranque.

Ese es un buen argumento para deshacerse de este gestor de arranque y es un algoritmo de suma de comprobación ridículamente ingenuo. Lo que normalmente hago es ni siquiera intentar sumar paquetes individuales. Diseño el protocolo para una eficiencia razonable, pero añado una buena suma de comprobación a toda la imagen.

Comunicar los datos desde el host al dispositivo es solo una parte del problema. Entonces tiene que escribirse correctamente en la memoria no volátil. Eso es en realidad mucho más probable que falle. Una falla de energía, o el usuario presionando el botón de reinicio en un mal momento puede causar corrupción, por ejemplo.

Mi estrategia generalmente es no preocuparse por los posibles errores en los pasos individuales del proceso, sino verificar el resultado final. Por lo general, coloco algo así como una suma de comprobación CRC de 24 o 32 bits al final de la imagen cargada. Antes de que el gestor de arranque ejecute la aplicación principal, verifica la suma de comprobación. Si falla, solicita una nueva imagen, ejecuta la imagen anterior, señala un error o algo. Nunca ejecute una imagen dañada.

De un comentario:

El archivo binario contiene un Firmware (algunos .cy.h. y bibliotecas generadas con un IDE incorporado como Keil). ¿Cómo agregar esta suma de comprobación a la imagen en sí? ¿Es seguro modificar dicho archivo?

No, el archivo binario no contiene ningún archivo .c y .h. Es un archivo binario . Debe retroceder y aprender qué hacen el compilador, el bibliotecario y el enlazador, y qué tipo de información hay en los distintos tipos de archivos. No puedes ir desarrollando código donde estés cerca del hardware sin entender estas cosas.

Agregar una suma de comprobación al archivo binario (a menudo en formato Intel Hex) es una forma de añadir una suma de comprobación a la imagen. Podría escribir una herramienta separada que se ejecute después del enlazador. Esta herramienta lee la imagen, calcula la suma de comprobación y la incrusta en la imagen en un lugar conocido.

Otra forma es que el programa de carga agregue la suma de comprobación sobre la marcha. El cargador lee el archivo binario no modificado y agrega la suma de comprobación en las ubicaciones conocidas, generalmente los últimos bytes de la imagen. Esta imagen modificada se envía al cargador de arranque, pero el archivo binario nunca se altera.

Deseas escribir tu propio gestor de arranque pero citas la nota de la aplicación para el incorporado en uno. Olvida este.

Escriba el cargador de arranque y lea solo el Manual de referencia. Olvide el bootlader integrado y sus "comandos"