Bootloader questions

[Eoin87]

Hi all,

I'm currently building a wireless boot-loader for PIC24F. I have some questions about how I could generate an object file from my project code.

The problem is the following, the Hex File and the addresses in each line are not sequential, this makes the standard bootloader quite complicated because Flash Memory is only programmable in sectors of 64 instructions. Therefore when I am reading through the hex file, there will be breaks between sectors in program memory which are programmable. This will lead to very slow programming.

Is it possible for the compiler to generate a file which simply give a list of the instruction at each memory location. This would allow for much faster programming of the device.

Any ideas thoughts?

Eoin

[jeremiah]

Well the nice thing is you can write 0xFFFF in words that are not currently being written to until those data values are read from the file, so while, yes slower, you don't have to re-erase the block which is nice.

In general I have found most files to be in order, but you are right, I have seen some that are not in order.

The tricky thing with CCS and non sequential hex files is that the write_program_memory() function will erase the block automatically if the address supplied is on a page boundary. This can get you if you have already erased a block but written to other parts of it prior to calling it for a page boundary address. I ended up having to write my own copy of write_program_memory() that didn't call the erase and managed the erases manually.

In terms of if you can generate a file with specific order of instructions...I don't think it is possible, but maybe a more experienced person here can comment. I've tried using #ROM statements to force stuff, but in the end, the hex file was still out of order, so not sure on that.

[Eoin87]

Exactly my thoughts

Thanks for clarifying that, I managed to read the program memory and save to a file on my PC.This way I should be able to write sequentially in full blocks and save time.

Thanks!

[Ttelmah]

Yes, I'd say to a question like this, read it into MPLAB, and write it out from this. It'll then be sequential.

Best Wishes

[RF_Developer]

[asmallri]

I just want to make sure I understand the comments in this thread correctly. I interpreted Eoin's original post to mean the hex file was disjointed but contiguous (i.e. each record is located in memory above the previous record).

However Jeremiah is saying he has seen examples where the records are not contiguous (i.e. a record may be destined for a memory location lower in program memory than the current record). Personally I have not seen this from CCS hex file or Microchip hex files. Also, knowing how some commercial programmers work, they would fail as a result.

Question for Eoin - is the problem you are experiencing because the record is disjointed but contiguous?
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[Ttelmah]

[jeremiah]

Yeah, when he said not sequential, I was thinking "out of sequence" rather than "missing chunk". I think I misunderstood what he meant. My apologies.

[Eoin87]

Often when I looked at my hex files I saw sudden jumps in the addresses.
From the above posted example, one can even see the initial goto being written to location 0x0000 and the main body of the code being written to 0X4800.

heres another example from one of my .hex files

[asmallri]

[jeremiah]

Eoin87,

One thing you can do to combat the "missing chunks" issue is to have a page sized buffer in your bootloader, initialized to 0xFF in all bytes. Then just fill in data as you get it from the downloader and do a single write.

The gotcha for this method is the issue I was highlighting (and mistakenly thought you meant) where memory jumps around, preventing you from saving data to a page sized buffer completely before data from the next page is introduced. In that scenario, you would just have to write what you have, and eat the "extra" time spent on any later chunks for that page. Remember, you can write 0xFF to any program memory spot as many times as you want as it doesn't change the current value of the spot, so overlap from 0xFF won't hurt you.

Asmallri,
One thing I have been experimenting with to combat this is to rewrite the write_program_memory() method to not erase if the address is a multiple of the page size. Then what I do is when the bootloader starts, it just bulk erases all pages in the user application space before it even determines which pages will be written to.

Now this method means I will be erasing pages that I may not be using, but all pages will have roughly the same lifetime at least. I still may have to deal with not having all of a page's data at once, but I won't have to erase the pages over and over due to data being out of order.

[Eoin87]

Getting back to this, reading the program memory and saving to a file works like a charm Very efficient programming.