[QUOTE=TheAnswer]Es extraño

Si cambio algun byte del principio del archivo este no se envia.

Pero si cambio algun byte por la mitad o al final, se envia hasta encontrarse con ese cambio y para.

Solo cambie la letra de un canal.

Puede que cada parte del archivo tenga su propio "CRC" y al estar enviandose el serialtrans o el deco lo comprueba y si nota un cambio para?[/QUOTE]

Eso puede ser por algo parecido a lo que yo decía: que al principio del archivo haya una especie de cabecera o algo así (que quizá en los firms de 5 archivos vaya en uno aparte), y que después estén los bytes de datos del firmware propiamente hablando. De esta forma, si se toca algo de la cabecera, sería más peligroso (puesto que no sabemos qué formato tiene, ni tamaños, ni nada), mientras que si tocamos algo de los datos el proceso de update sí que comenzaría hasta que detecte la "inconsistencia" o algo así.
Ya digo que yo no tengo ni idea de cómo estará hecho realmente, pero lo que yo haría si tuviera que diseñarlo (y he trabajado con cosas muuuuy parecidas) sería:
- poner una cabecera con los campos que me intersase. Entre ellos, pondría 1 con info del CRC de los datos reales. Por supuesto, sabría cuánto ocupa cada campo.
- Luego cuando se hace el update, el deco lee la cabecera, trocea aparte los datos y calcula por su cuenta el crc para comprobar que coincide con el de la cabecera. Lógicamente, sería posible que los datos a su vez estén troceados, de forma que en la cabecera esté el crc de cada trozo (pongamos que el deco tiene un buffer de 4096 bytes, por decir algo; con lo que iría recibiendo vía serie cada trozo, e iría calculando el crc de cada trozo en su buffer y comparándolo con lo de la cabecera)

Pero vamos, todo son suposiciones. Hasta que alguien no desensamble el software del deco que gestiona el update del firmware o nos hagamos con una especificación de formato de los ficheros de firmware, todo son pruebas y suposiciones a ciegas...