PIC24FJ32GA002 Program Memory

[LFern]

Hi All,

I have a bootloader (similar to ccs example bootloader) which can download a target application to the program memory over UART.

This bootloader does not changing the address 0, which contains a GOTO to bootloader's main address.

I have noticed that for some reason, ISR region is not updating with correct values.

I cross checked with the record's values against program memory written values. Also I did a printf just before write_program_memory function. All I can see is it does not writing which it should write.

All the other program memory seems okay.

I have a program memory table snap shot here, problem is with addresses: 0x24, 0x2A, 0x50. These values updating to something else, but not for the values in records.

Your comments are highly appreciated.

[FvM]

An obvious assumption is, that the bootloader is designed to keep block 0 of the program flash or that the block has been write protected.

As discussed in previous threads about PIC24 bootloader design, both would be reasonable measures to make a fail-safe bootloader. But of course, interrupts have to be redirected in this case and bootloader must be aware of the interrupts used in the application.

If your bootloader is freely overwriting block 0, there may be a problem with the correct handling of non-continuous flash images in your programming function.

[LFern]

FvM, Thanks for that info.

If I started with bootloader, first time I can download the target application without any problem. in this case, I can see the ISR region is all FF before downloading the target application.

At first time downloading, it keeps location 0 unchanged and do update the required ISR's with correct values.

If I run this second time, it does not update the ISR region with correct values. Instead ISR region is updated with some other values. these incorrect values remain same even if I did the process again and again starting with a empty program memory.

simplify the process:
started with ISR address, 0xFF -> updated to 0xABC -> updating to 0xDDD -> unchanged 0xDDD.
-> indicates a download process.

My really concern is why write_program_memory function writes invalid values at the second time?

If any erase problems are there, why it writing at the very first instance?

Any clues?

[FvM]

It's a question of how code for block 0 is arranged in your *.hex file. If it's continuous, there should be no problem. If you are including hex image data in your project, they may be non-continuous.

As a test, you can load and rewrite the hex file with MPLAB, which makes the hex data continuous. If it's working with the regenerated hex file, than it's a problem of the said kind.

[LFern]

The target hex file is something like:

:04004800A00D000007
:04005400EA0D0000B1
:0400A000740E0000DA
:100400003220EF00C3202000008041001040BA00DD
:100410000160EF0000000600537500006E00000050
........

which first 3 records are for 3 ISR's and it seems it is non-continuous.

According to these 3 records, ISR address values should be DA0, DEA and E74. but when I write this the second time, these values are not correct.

[FvM]

[LFern]

I hard coded following in my bootloader. which should update to the second value. but it is not. Now I can feel that write_program_memory function does something funny here.

[Ttelmah]

You need to understand memory write pages.

Read the 'additional notes', under the write_program memory command.

Then realise that the write_program memory command, _will not erase a page, unless you write to the first address in the page_.

So, when you write '11','22','00','00' the first time, the page is empty, and the write is OK. Then on the second write, since there is no erase, the _extra_ bits you specify, get set 'on top' of what you have already written, so you should see (I Think), '33','66','00','00'.....

To write these bytes, you need to read the _entire_ page into a RAM buffer, change the bytes you want, and write the whole page back, which will then trigger an erase, since you then write the first byte.

This is what FvM had to do - "I added a sector buffer to the bootloader flash programming code to handle non-monotonic programming data."
You need to do the same.

This is also why the default bootloader assumes you do not change the boot, and interrupt handler addresses, leaving these fixed as first written.

Best Wishes

[LFern]

Thanks all, I make it to work!

Added a sector buffer...