I had a requirement that Bootloader to be placed int the last page of flash and from there divide the remaining flash into 2 parts and if burn the code for the first time then the code should be written at the first location and then if i burn the code 2nd time it should burn in the second location and reset should be changed to that address if 2nd program was not burn properly then it should point to the first location address as reset . That means i should be able to change the reset address how can i do this in pic . Is this possible or any other way if you suggest we can even try that how ever i need to have 2 programs one should be executing and for safe side

And if it works then if i burn the program odd number times it should write in the first location and reset should point to first location and if we burn even number of times it should write in 2nd section and reset should point to the 2nd location. and if program was not burn properly it should point to the previous reset location

 

This is not good design.

Add a pushbutton, that is hold down at power up.
Then bootloader is entered, otherwise user program space.

 

The first thing you omitted is how is this new code going to get into your PIC? RS232 is about the only pathway you have available. The good news is there is app code (AN1310) to do just that. (The bad news is it is written in assembler.)

It appears you have two application files in your program so there is always a "safe" copy there. I've never seen it done that way, and I would question if you would actually gain anything that way. But it's your app and your call (though it sounds to me like something "management" added).

A bootloader typically works like so: On power on reset the bootloader runs and tests some switch: a real button thru a pin, some specific memory location, or something else. If the test fails then the app code is run. If it passes then the target ROM is erased, the new code is downloaded and burned to the ROM, and then the app code is run via a jump.

In your case you also need a place to store the odd/even value, offhand the EEPROM may be a good place to put this. Alternatively, the source could have some sort of time stamp that could be tested and used to pick which app code is actually run. But the EEPROM choice may be best as it may be simpler to implement a "rollback" feature implied in this bootloader. It could work in the code if you are able to erase the new code and have it recognized as "older and hence not run.

The application source code *will* need custom two link scripts to place it in either of the two destinations. This opens up the possibility that a user who misses an update will overwrite the wrong code like so:

Device ships with code rev A in location A. Next update rev B goes to location B. All is well.

Update rev C is missed by customer and does not overwrite rev A.

Now update rev D is shipped and installed. As it is an odd number it is installed into location B, so the memory is now rev A and rev D, and any rollback skips rev B and goes right back to rev A.

It may be possible to always ship two versions of the app code and let the bootloader use the appropriate one but this will require additional hand shaking inside the bootloader itself (to reject one source and use the other).

So while this could work I do think you need to carefully consider all the implications.

 

An option might be to end each new program with the data "Version 2001 OK", "Version 2002 OK", etc. This should be written after the new program has been checksummed.
The reset code can just check for the latest number.