Bootloader para PIC24EP?

He completado con éxito bootloader para pic24EP256GP204 . Hubo dos problemas con mi gestor de arranque:

1. El primer error en mi gestor de arranque fue en la interpretación del formato de archivo HEX para los microcontroladores pic. %código%. Yo no sabía eso. Estaba usando esa dirección directamente sin dividirla. Por lo tanto, necesito dividir la dirección en un registro de archivo hexadecimal entre 2 y debo usar esa dirección para la imagen de programación.

2. El segundo error fue al escribir el flash. Mi imagen ( The address field in the hex file is double that of the PIC device address ) solo admite la operación de escritura flash de doble instrucción. Estaba cometiendo un pequeño error al escribir las instrucciones si necesitamos escribir una sola instrucción. Encontré algo de código en línea usándolo. Puedo escribir una sola instrucción al enmascarar la instrucción superior o inferior con una operación de escritura de flash de doble instrucción. El código que encontré está pegado a continuación:

   unsigned NVMemWriteWord(uint32_t address, uint32_t data)
   {
   DWORD_VAL writeAddress;
   DWORD_VAL writeData;
   
   writeAddress.Val = address;
   writeData.Val = data;
   
   NVMCON = 0x4001;        //Perform WORD write next time WR gets set = 1.
   NVMADRU = writeAddress.word.HW;
   NVMADR = writeAddress.word.LW;
   
   // Set the table address of "Latch". The data is programmed into the FLASH from a temporary latch. 
   TBLPAG = 0xFA;
   //The smallest block of data that can be programmed in
   //a single operation is 2 instruction words (6 Bytes + 2 Phantom Bytes).
   // Mask the high or low instruction words depending on the address and write either high or low instruction word.
   if(address % 4)
   {
       __builtin_tblwtl(0, 0xFFFF);                //Mask the low word of 1-st instruction into the latch.
       __builtin_tblwth(1, 0x00FF);                //Mask the high word of 1-st instruction into the latch. (8 bits of data + 8 bits of "phantom data" (phantom byte is always 0))
   
       __builtin_tblwtl(2, writeData.word.LW);     //Write the low word of 2-nd instruction into the latch
       __builtin_tblwth(3, writeData.word.HW);     //Write the high word of 2-nd instruction into the latch        
   
   }
   else
   {
       __builtin_tblwtl(0, writeData.word.LW);     //Write the low word of 1-st instruction into the latch
       __builtin_tblwth(1, writeData.word.HW);     //Write the high word of 1-st instruction into the latch 
       __builtin_tblwtl(2, 0xFFFF);                //Mask the low word of 2-nd instruction into the latch.
       __builtin_tblwth(3, 0x00FF);                //Mask the high word of 2-nd instruction into the latch. (8 bits of data + 8 bits of "phantom data" (phantom byte is always 0))
   
   }       
   
   INTCON2bits.GIE = 0;                            //Disable interrupts for next few instructions for unlock sequence
   __builtin_write_NVM();
   while(NVMCONbits.WR == 1){}
   INTCON2bits.GIE = 1;                            // Re-enable the interrupts (if required).
   
   // Return WRERR state.
   return NVMCONbits.WRERR;
    }
   

Más o menos ampliando mi comentario aquí. No estoy al 100%, pero el formato hexadecimal parece ser intelhex. Estoy utilizando el visor hexadecimal proporcionado por el programa Segger JFlash para ver el contenido del archivo hexadecimal.

Sus direcciones están comenzando en 0x0, no hay duda al respecto. Si su secuencia de comandos de Python está enviando ingenuamente los bytes a su mcu, de hecho enviará direcciones dentro del rango 0x200-0x005BF0. He adjuntado un fragmento de su archivo hex que ilustra que la dirección base del archivo hexadecimal es 0x0.

¿Apuntaste tu vinculador al archivo .ld correcto?

La solución rápida es simplemente ignorar estas direcciones fuera de los límites con su script de python. También puede ignorar los fuera de los límites en el lado del mcu, pero esto puede dar lugar a errores silenciosos y desagradables cuando no está totalmente actualizado.

Una solución más completa es averiguar por qué el script del enlazador no está haciendo lo que le estás diciendo. No estoy familiarizado con el lenguaje del enlazador de imágenes, pero he hecho algo similar con un núcleo Cortex M-0 y una cadena de herramientas GCC. Recomiendo encarecidamente buscar una guía. Su caso de uso no es inusual y estoy seguro de que está documentado. Me disculpo por no poder ofrecer más orientación, pero un rápido google de "pic bootloader linker script" produjo algunos resultados prometedores.

Un fragmento de su archivo hex cargado, que ilustra el contenido en 0x200.  

Permaneceenblancohasta0xC000,dondeparecequeseinicialaaplicación:

EDITAR PARA RESPONDER A UNA PREGUNTA EDITADA:

Necesitas depurar este nuevo problema. Suena como si tu tabla vectorial estuviera dañada. Use una herramienta como MPLAB IPE para descargar el contenido flash de su MCU y verifique que su cargador de arranque mcu no esté haciendo nada tonto con sus tablas vectoriales.

Como otro método de solución de problemas para el cargador de arranque PIC, puede agregar el proyecto MPLABX del cargador de arranque como "cargable" de su proyecto de aplicación principal. El compilador luego le dará advertencias sobre cualquier superposición de memoria o conflicto según lo definan sus archivos de enlace individuales.

Para agregar un cargable, haga clic derecho en el proyecto de su aplicación y haga clic en Propiedades. En Conf / Loading selecciona tu proyecto de gestor de arranque.