Duda con memoria bootloader PIC24/dsPIC33

[dhmejia]

Hola, tengo una aplicación con un PIC24EP512GP806 (que reemplazo sin problemas por el dsPIC33Ep512GP806), la aplicación usa una unidad GPS/GPRS para comunicación con un servidor de datos y tengo una memoria flash serial (SST25VF040B) que uso para hacer log de algunos datos importantes. El caso es que ahora necesito agregar la funcionalidad para actualizar el firmware de manera remota, el programa como tal no es muy grande y solo ocupa el 5% del total disponible en el micro, por lo tanto considero que puedo usar la misma memoria para logs y almacenamiento temporal del nuevo firmware.

He buscado información y contaba con que fácilmente se encontraba un bootloader ya listo que pudiera usar en mi aplicación, pero generalmente lo que se encuentra son aplicaciones para actualizar el firmware desde una conexión serial o USB, en mi caso no puedo usar la conexión serial ya que el canal con la unidad GPS/GPRS no es muy estable y el servidor puede demorar mucho en enviar un paquete de datos. Por lo tanto me empecé a documentar con el tema y parce que es tan simple como hacer lo siguiente:

-Recibo los datos línea a línea desde el archivo .hex, verifico el checksum y guardo la línea en la memoria flash serial.
-El sevidor recibe la notificación de cada línea que se ha recibido correctamente, sin esta notificación no se envía la siguiente línea.
-Al terminar de recibir el .hex el servidor debe enviar el comando de actualización.
-Se llama a la función de actualización, que carga los datos de la flas serial y los graba en la memoria de programa del micro.

Estos micros tienen una zona de memoria flash secundaria en la cual estoy alojando las funciones del bootloader, que básicamente son la lectura de la flash serial y la re programación del micro. Lo demás se procesa desde el programa principal. En la forma en que pienso hacer el desarrollo parece que no debo preocuparme por re direccionar los vectores de interrupción ni reescribir la posición de memoria de reinicio para apuntar al bootloader, aunque aún tengo dudas con esto.

Aún no desarrollo nada de lado del servidor, pero teóricamente ya tengo la parte de recibir las líneas del .hex y almacenar en la flash serial, todo muy bien hasta que empecé con la función de re programación, cuando me encontré con el tema del byte fantasma de los pic de 16 bits, además de que el dato en una posición de memoria no me corresponde entre el archivo .hex y la memoria de programa que me muestra el mplab.

Por ejemplo, la segunda línea del .hex tiene esta información:

:080000000002040000000000f2
La cual según entiendo corresponde a:
08: 8 bytes de datos
0000: posición de memoria 00000
00: tipo de data record
00020400: dato a grabar en la posición 0000
00000000: dato a grabar en la posición 0001
f2:checksum

Sin embargo el mplab muestra esto:
Line: 2, address 0000, opcode: 040200
Line: 3, address 0002, opcode: 000000

Otro caso para aclarar:
:100400004f9721000eff27000e018800000000001a
10: 16 bytes de datos
0400: dirección 0400 que dividida entre 2 sería la 0200
00: tipo data record
4f972100: dato a grabar en la posición 0200
0eff2700: dato a grabar en la posición 0202
0e018800: dato a grabar en la posición 0204
00000000:  dato a grabar en la posición 0206
1a: checksum

el mplab muestra:
line 258, address 000200, opcode 21974F
line 259, address 000202, opcode 27FF0E
line 260, address 000204, opcode 88010E
line 261, address 000206, opcode 000000

según veo el 4to byte de cada dato es el byte fantasma, eso me queda claro, pero al momento de grabar debo hacer un byte reverse o algo así? porque el opcode que muestra el mplab es invertido, pero me queda la duda de si se graba normal y solo es una forma de mostrar en el mplab.

También tengo muchas dudas respecto a la forma de grabar el micro, pero vamos por partes.

Cualquier información o guía les agradezco mucho.

Saludos,

[KILLERJC]

Ese byte de mas, tal ves sea por que el Intel HEX es de 8 / 16 o 32 bits. Como las instrucciones son de 24 te estarian sobrando esos 8, Y lo paddea, es mas facil dividir por 4 que por 3 en un microcontrolador.

Y si, el endiannes es distintos. El address si o si esta en Big Endian, por eso no lo modificas, y los datos no hay nada que diga como ponerlos, Pero estan en little endian.

Imagino que esto esta asi por que al grabar por ICSP el primero en enviarse es el LSB.

[dhmejia]

Gracias por la respuesta, entonces lo que entiendo es que si debo armar el paquete de los 3 bytes cambiando el orden en que están en el .hex para grabar finalmente en el micro.

[KILLERJC]

Si queres usar el forma del .hex para grabarlo si.

Usualmente si se trata de un producto comercial y esperas que el mismo pueda actualizarse, lo minimo que deberias hacer es codificar el codigo, sino le estarias dando el codigo a cualquier persona, habilitandolo a que te copie todo el proyecto con solo hacer ing. inversa de la PCB nomas.

Sea cual sea que ejecutes como memoria auxiliar, por ultimo vas a tener que grabar de nuevo las palabras de configuración.

Ej...

Memoria Principal: Programa
Memoria Auxiliar : Boot

- Programa al detectar el pedido de actualizacion, debe cambiar el bit de configuracion RSTPRI, que es quien selecciona que memoria usar. Y reset del micro. (No podria aplicar ningun salto, dejaria la RAM con lo ocupado del programa)
- Aca entra el boot a pedir datos y grabar el micro. Vas a tener que manejar posibles problemas aca, como falta de datos (timeout), reintentos, marcado de numero de lineas, proteccion por falta de tension, etc. Lo bueno de esto es que al iniciarse el boot, si se resetea comenzaria todo de nuevo. Pero el server debe manejar ese problema.
- Luego de que se termino de grabar debes volver a grabar los bits de configuracion para que inicie en el programa principal. Esto al ultimo por si es que existe algun problema al momento de la grabacion, asi cualquier cosa inicia el boot de nuevo.

Otras opciones a considerar es en ves de mantener el programa NUEVO en la flash, seria mantener el programa viejo. De esa forma si luego de grabar el boot, el programa NO inicia o se detecta algun problema. Se puede volver a la version anterior que si funcionaba. El programa nuevo lo vas tomando linea a linea, decodificando y guardando en RAM.

Lo unico feo de esto es que tendrias que repetir casi todo el codigo de inicio, manejo , etc.
Pero con solo 5% ocupado no tiene mucho sentido preocuparse.

cuando me encontré con el tema del byte fantasma de los pic de 16 bits,

Ahora que lo veo, cuando uno trabaja con tablas y programacion en flash, los registros son de 16bits, lo cual seria raro enviar solo 8 y luego 16 (Incluso para manejarlo con algun programa), para eso se envia 16 y 16 (tratas a todos como de 16bits),  por eso estarian los ceros incluidos. A pesar que el byte de mayor peso sea puros ceros.

[dhmejia]

Que buena información, no tenía claro el manejo de la flash auxiliar y lo estaba manejando como un salto. Me suena mucho más la implementación que me sugieres, de mantener la versión normal en la flash y cargar en ram la actualización parte por parte. Respecto a la protección lo que estaba asumiendo es que como el hardaware funciona en conjunto con el server entonces la copia del harware no produce un producto viable por si solo, pero si me parece que es más seguro incluir algún tipo de encriptación, la ventaja es que tengo capacidad de procesamiento de sobra.

Voy a ver si logro avanzar la próxima semana y publico los avances.

Saludos,