Electronic – Bootloader for PIC24EP

bootloaderpic

I am working on pic24EP bootloader. My bootloader has it's own packet format to communicate with a python script to update the firmware of the microcontroller. The bootloader resides at the first free page after Interrupt Vector Table (0x000800). To make space for application, i have edited linker script of my application firmware so that application hex file wouldn't use any space in between 0x200 and 0x005BF0. The linker script of application project is given below:

/*
** Memory Regions
*/
MEMORY
{
  data  (a!xr)   : ORIGIN = 0x1000,        LENGTH = 0x8000
  reset          : ORIGIN = 0x0,           LENGTH = 0x4
  ivt            : ORIGIN = 0x4,           LENGTH = 0x1FC
  program (xr)   : ORIGIN = 0x6000,        LENGTH = 0x23FFE
  FICD           : ORIGIN = 0x2AFF0,       LENGTH = 0x2
  FPOR           : ORIGIN = 0x2AFF2,       LENGTH = 0x2
  FWDT           : ORIGIN = 0x2AFF4,       LENGTH = 0x2
  FOSC           : ORIGIN = 0x2AFF6,       LENGTH = 0x2
  FOSCSEL        : ORIGIN = 0x2AFF8,       LENGTH = 0x2
  FGS            : ORIGIN = 0x2AFFA,       LENGTH = 0x2
  FUID0          : ORIGIN = 0x800FF8,      LENGTH = 0x2
  FUID1          : ORIGIN = 0x800FFA,      LENGTH = 0x2
  FUID2          : ORIGIN = 0x800FFC,      LENGTH = 0x2
  FUID3          : ORIGIN = 0x800FFE,      LENGTH = 0x2
}

__FICD = 0x2AFF0;
__FPOR = 0x2AFF2;
__FWDT = 0x2AFF4;
__FOSC = 0x2AFF6;
__FOSCSEL = 0x2AFF8;
__FGS = 0x2AFFA;
__FUID0 = 0x800FF8;
__FUID1 = 0x800FFA;
__FUID2 = 0x800FFC;
__FUID3 = 0x800FFE;
__CODE_BASE = 0x6000;
__CODE_LENGTH = 0x23FFE;
__IVT_BASE  = 0x4;

__DATA_BASE = 0x1000;
__DATA_LENGTH = 0x8000;

It looks like my bootloader rejects firmware (hex file) at some point as it has address in between 0x200 and 0x005BF0 but i have edited the application linker script to only use addresses above 0x6000 by modifying variables: __CODE_LENGTH and program.

The memory map of my micro-controller is below:

The size of flash is 256kB and page size is 1024 instructions (1024*4 Bytes). The Hex File is over here. And the linker script is over here.

EDIT:
I have solved my problem. Looks like PIC uses a slighty different HEX File Format than INTEL. The addresses in HEX file are 2 times the real address in PIC. So, i need to divide the address in hex file by 2 to get flash address of PIC microcontroller.

However, i have identify new issue with my system. I am not able to post a new question. So, i am adding it here. Now, my application(well tested) uploaded via bootloader works until any interrupt fires up. If any interrupt fires up, it hangs. All i can check is that it doesn't end up in any trap. Can anyone point me to right direction?

Best Answer

I have successfully completed bootloader for pic24EP256GP204. There were two issue with my bootloader:

The first bug in my bootloader was in interpreting HEX file format for pic microcontrollers. The address field in the hex file is double that of the PIC device address. I didn't know that. I was using that address directly without dividing it. So, i need to divide the address in a record of hex file by 2 and should use that address for programming pic.

The second bug was in writing the flash. My pic (pic24ep256gp204) supports double instruction flash write operation only. I was making a small mistake in writing the instructions if we need to write a single instruction. I found some code online using it i can write a single instruction by masking either the upper or lower instruction with a double instruction flash write operation. The code i found is pasted below:

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;
 }

Related Solutions

Electronic – Force xc32-ld to place all application code in kseg0_boot_mem

The C compiler will place the C-runtime startup code in the kseg0_boot_mem, which sets up the stack, heap, and general processor initialization. The amount of code placed in kseg0_boot_mem will vary between a debug and release build. If I recall correctly, when I was working on a bootloader for a PIC32MX250F, the debug build took up ~70% of the kseg0_boot_mem, which wasn't enough for my bootloader.

If your bootloader is small enough to fit into the kseg0_boot_mem along with the C startup code, reduce the size of the kseg0_boot_mem, and then relocate kseg0_program_mem to above the new boot_mem space. Note that you cannot move the starting location of the kseg0_boot_mem space. Code excecution starts at 0xBFC00000 on the PIC32, and there is nothing you can do to change that. If you want to move the entire bootloader, you will also have to move the ISR table. For example:

MEMORY
{
  kseg0_program_mem    (rx)  : ORIGIN = 0xBFC01200, LENGTH = 0x1DF0 /* kseg1_boot is 2FF0 long.*/ 
  kseg0_boot_mem             : ORIGIN = 0x9FC00000, LENGTH = 0x1000 /* This memory region is dummy */ 
  exception_mem              : ORIGIN = 0xBFC01000, LENGTH = 0x200 /* Relocated ISR table. */
  config3                    : ORIGIN = 0xBFC02FF0, LENGTH = 0x4
  config2                    : ORIGIN = 0xBFC02FF4, LENGTH = 0x4
  config1                    : ORIGIN = 0xBFC02FF8, LENGTH = 0x4
  config0                    : ORIGIN = 0xBFC02FFC, LENGTH = 0x4
  kseg1_boot_mem             : ORIGIN = 0xBFC00000, LENGTH = 0x1000 /*This has been reduced in size.  Was 0x2FF0*/

  kseg1_data_mem       (w!x) : ORIGIN = 0xA0000000, LENGTH = 0x8000
  sfrs                       : ORIGIN = 0xBF800000, LENGTH = 0x100000
  debug_exec_mem             : ORIGIN = 0xBFC02000, LENGTH = 0xFF0
  configsfrs                 : ORIGIN = 0xBFC02FF0, LENGTH = 0x10
}

NOTE: this is just a sample bootloader script, and should in no way be copy-pasted into production!

With that said, I can speak from experience that trying to cram a non-trivial bootloader into the boot_mem program space does not work out. The space left over from the C startup code usually is not enough, particularly if you want some heavy error-handling and validation (and yes, you DO want this!). Removing the debug builds from the very limited arsenal of embedded debug tools is not good either. You will need to be able to debug on hardware at some point in the future. I learned that lesson the hard way.

My recommendation is to leave the kseg0_boot_mem code section alone, and just work with the kseg0_program_mem space. Grab a slice of the kseg0_program_mem at the top or bottom (doesn't matter) and use that for your bootloader code and ISR table. Leave yourself some room for bootloader code growth as well. Dealing with multiple linker scripts is a bit of pain.

Electrical – Loading a HEX file with PICkit 2

I think I know the problem. In your first hex file, the alignment is correctly on 2 byte, with 16 bytes on each line. The first few addresses are (in hexadecimal):

Notice how the addresses go up in increments of 16bytes (10h), but crucially, notice how the lower digit is always zero (well strictly speaking a multiple of 2).

In the corrected hex file, the addresses are:

Here they are no longer correctly aligned. Notice how the lower digit is not a multiple of 2 - it is 9.

This is a problem simply because the PIC's program memory is organised in 2byte (16bit) chunks - each instruction is 16bit or 32bit IIRC.

Technically the hex file is correct, however it will confuse the heck out of the tools because technically address 0x6829 does not exist (0x6828 and 0x682A both do). The PICKit software will realign the hex file when it opens it - essentially adding in an extra 0xFF word at the beginning to realign the data to the correct place, and as a result the upload works and the program runs fine.

As to why it is happening, I really haven't a clue beyond a bug in a toolchain which is already glitchy at the best of times (the reason I gave up with PICs and went for AVRs instead!).

There may be a setting somewhere in the project to select the alignment of the hex file. If not, perhaps you could try adding an extra byte sized variable in the program memory (or make an existing one an extra byte in size) and see if that tricks the toolchain into realigning the hex file.

Best Answer

Related Solutions

Electronic – Force xc32-ld to place all application code in kseg0_boot_mem

Electrical – Loading a HEX file with PICkit 2

Related Topic