Bootloader for PIC24FJ32GA002

[LFern]

Hi All,

I am trying to do come up with a bootloader who is capable of handle power cycling problems while doing the update.

The bootloader example in PICC/examples/ is basically a serial bootloader which is going to an unknown state upon power cycle during the update is going on.

What I suggest is 3 stage update mechanism with the example bootloader as follows:

Assume now the chip is in bootloader mode, expecting an application through serial port.

step1: send application.hex file without the very first record which contains information to update program memory 0th location with GOTO application's main function. reason: upon power cycle, program memory still have the bootloader's main function at location 0. which restarts the bootloader process.

step2: after sending complete application, sends the application.hex file's very first record which contains information to update program memory 0th location with GOTO application's main function. reason: now it is safe to update location 0 with GOTO application's main function as application successfully downloaded.

The problem here is I can do the step 1 without any issue and can verify by reading the program memory back. But when I execute step 2, it actually erase the program memory 0x00- 0x400, which 0x400 is the application main function's address.

I can see isr are there below 0x200. but they also get deleted and 0th location got updated successfully.

the very first record contains only 8 bytes starting from address 0. It doesn't seems updating anything else except 0th location.

Any ideas why 0x00 - 0x400 deleting when just updating 0th location?

I am using write_record_to_memory as it is in the example bootloader.

Thanks,

[FvM]

[LFern]

Thanks FvM,

The problem exactly is the full page erase by the write function when try to write on page start address.

With this PIC24F the page size is 0x800 and I successfully handled the fail safe bootloader functionality.

Let me brief what my PM (Program Memory) architecture is:

I have two main functions in side the PM. One is bootloader-main and the other one is application-main.

Bootloader-main is in PM address 0 at factory level. When it comes out from the factory, during the first configuration application program is download through the bootloader. Here application hex file writes except the first record which is trying to override the PM current address 0. So still PM adress 0 is in bootloader-main which is fail safe!

Just before the EOF in application hex, it includes the first record and upon receiving that, bootloader first reads 0x00 - 0x800 on to PIC24F RAM and do the 0x00 change and writes back the 0x00 - 0x800 page ensuring PM address 0 having the application main.

I have tested this and working fine.

[FvM]

Your post still refers to unreasonable address ranges like 0 to 0x800. 0x800 belongs to the next page. I guess, this is only a typo.

Personally, I won't erase bootloader parts, even with RAM backup, because it's a possible reason of unrecoverable bootloader failure, at least in case of power loss.

Another possible problem in bootloader operation, that isn't handled by the CCS bootloader exampler sufficiently, is raised by discontinuous hex files. If I remember right, I discussed it in one of my PIC24 bootloader related posts.