Problem with dsPIC30F6014A bootloader

[naughty_mark]

Hi everyone,

I got a problem with dsPIC30F6014A micro with CCS compiler v5.016.
I use the bootloader code that CCS provides, its name is "ex_bootloader.c" with minimum changes. For give a full picture, I list those minimum changes even that is not the root cause of my problem. Changes are:
a. when get address 0x0000, record that RESET goto address into E2 so that program can read the value from E2 when power on and enter main program if there is no bootloader triggered. The reason I did that is I failed to use CCS way to let micro grab the entry address of main program automatically. That way works anyway.
b. send pos/neg feedback when got hex code from PC side, so the bootloader can run under higher baudrate with re-send strategy for stabilization.

On PC side, I program a simple hex file sender with re-send strategy by VC++, and it works well.

For my project, there are two firmware : full version and cutdown version using one same hardware. After I programed my bootloader code into the uC with PIC kit3, they are both working if those firmware is the first one to downloaded by bootloader. Which means after bootloader programmed, if I use it to download full version firmware firstly, full version works very well. If download cutdown version firmware firstly, cutdown version works well. However, if the firmware is downloaded at the second time or say not first time by using bootloader, it doesn't work. For example, after I programmed bootloader, then I use bootloader to download full version firmware, full version works. Then I use bootloader again to refresh the main program from full version to cutdown version, the cutdown version doesn't work. It is same if the order is reversed. Some points I already check and make sure they are fine:
a. The bootloader code in uC is fine, it is not corrupted while downloading the main firmware.
b. the corrupted firmware doesn't work or say partly work precisely, because it can implement ini hardware and ini my application, but can not run the timer based RTOS which I called scheduler function. Then I suspect either the entry address of "scheduler" function is corrupted or the interrupt vector is corrupted which leads the system time ticker not working.

Comparing with data of the working cutdown version firmware with not working one by reading program memory via PIC kit3, I found the address from 0x00006 to 0x00003E are corrupted, they are not same. The data from working sample is the same as HEX file, and the data from not working sample is not the same as HEX file. I even just cut these part hex file into a separate hex file and use bootloader just download this interrupt vector part, but the same result.
Is there anyone having this problem before, or is there something wrong I did.

Sorry for this Loooooong thread, I just wanna make clear to you guys and tell you what I checked and got.

I do appreciate you guys' help.

Kind Regards
Mark

EDIT:
More I got. As I said I just cut out this part in HEX to form a separate HEX file as below:

[Ttelmah]

I suspect your problem is with your approach, and 'pages'.

Since your code allows the target address of the main code to change, you have to change the data stored at address 0. This means you have to rewrite the page at the base of memory. You therefore need to _read_ the entire page at this address, change just the vector, and then write back the whole page.
Unless you do this, the rest of the first page will be corrupted.

Realistically, it is simpler, and safer, to use the CCS approach.

Reserve the memory amount corresponding to the larger bootloader, and make your code compile to reside above this address. Then the start address can remain unchanged, and (more importantly for long term safety), you can have the bootloader refuse to program any page that comes into it's resident area, and preferably enable the code protect on this area.

[naughty_mark]