Re-writing flash

I am in the process of writing code to reprogram my board. I am using a dsPIC33FJ128GP306 and I have a PC application that communicates with the board via USB (or Bluetooth depending on the board). Once this device is out in the field (sold to customers), there will be a need to load a new embedded image onto the device using the PC application. I've looked over example Bottloader_SW_022409 and it is helpful but not sufficient for my purposes. So here are my questions:

1) From what I gather, the code isn't actually run out of flash (program memory is some RAM type area in the processor would be my guess). Are there any issues in re-writing the flash while the dsPIC is running?

2) If the answer to question 1 is no (there are no issues), then can I just do a bulk erase of the entire flash and then reprogram it a page at a time?

3) It was mentioned in another post that there are 'tools' for re-writing flash on the dsPIC. Are there some built-in functions or something of that nature to make this easier? In reading through section 5 (flash programming) of the manual, it looks like it mostly is done using assembly code. And the example code provides a file called memory.s which looks like it would be useful. Is there something else available that I'm not aware of?

4) Do I need to have something like a boot loader running to be able to accomplish the re-writing of the flash? I guess this is really similar to question 1 above.

I think those are my main questions for the moment. I'm sure that more will come up as I work through this. Any help is greatly appreciated.

Thanks Calum. I was afraid that was the case. I've tried creating a boot loader (using a boot segment and a general segment) but haven't been very successful. Even though the code looked correct in program memory, the control would never successfully switch from the boot segment to the general segment and debugging this is pretty difficult. I guess I'm going to have to go back and try and make that work.

With regards to the library functions, I found them in the libpic30.h file so I will try and make use of them. Thanks for pointing me to those functions. I notice that the function _erase_flash() is actually the function _flash_helper1(). If I wanted to erase all of the general segment at one time, I would guess that I could call the _flash_helper1() functions like this:

_flash_helper1(0x2000, _FLASH_ERASE_GENERAL_SEGMENT_CODE);

This assumes that my general segment begins at address 0x2000. Is this the correct way to do that?

I could then reprogram everything in the general segment using the _write_flash24() function. If need be, I could also update the configuration registers and the IVT/AIVT tables.

The main reason for calling the helper function directly is that the existing one on allows for a single page at a time to be erased. It can certainly be used like that (a loop that goes through and erases all of the pages) but using a single call to erase the entire general segment would seem to be much more efficient. If they (the developers) don't think that is a good idea, then I'll just do it a page at a time. It's something that I would probably experiment with once I get the segment aspects working.

Speaking of which, I already have a post regarding segments from back in March. It doesn't seem like too many people are doing that sort of thing based on the responses there. I think it will be a fair amount of trial and error to get that all working. The one thing I did notice in rereading some of the documentation (I've read section 5 many times and I've read through the CodeGuard Security documents multiple times) is that the IVT and AIVT tables shouldn't be moved. In many of the examples on the Microchip web site, they do move the tables which is what I tried in the past. Perhaps I'll leave them alone this time and see if I can make it work in other ways.

One thing to keep in mind is that the public interface (defined in libpic30.h) will change rarely, if ever. So you have the advantage of consistency from release to release. The public interface also abstracts any device-specific parameters, so you have the advantage of consistency from device to device.

On the other hand, helper functions may change from release to release and do not always support every device family. So if you call helper functions directly, you must accept some responsibility for on-going maintenance.

Cheers