Firmware upgrade in MSP430F5419A controller without using boot strap loader

JIS JOHN said:

can we partition the flash and when an updated firmware is received through UART update the firmware to the second partition which is not being used and once the firmware is updated reset the code so that when the code is reset ted the  execution starts from beginning of the second partition.

That's almsot exactly how I handled this:

The area from 0xfc00 to 0xffff is occupied by a data-copy algorithm, a default vector table and a jumptable. This area is never overwritten and static, so it is always in working condition. The copy code checks the area from 0x10000 to 0x1ffff for a new firmware (including CRC etc.). If it is present, it erases the flash below 64k (without the topmost 1k) and copies from the extra flash to the lower flash. When this is done, the new firmware in upper flash is erased (the 5x family has  abank erase function that only erases one bank and not all main memory - convenient!).

If the flashing failed (e.g. due to power failure), the new firmware is still in upper flash and copying begins anew, until it finally succeeds.

The new firmware is received by the applciation through it snormal communication channels during normal operation (RF in most cases). Once the new firmware is received completely, the device makes a self-reset and the new firmware is copied. This keeps the device operational until the complete firmware update is received and checked, keeping the downtime low. And sinc ethe copy-code is never erased, you cannot brick the part by interruptint the update process.

Note that I, for convenience, use the upper flash above 64k for storage. But on MSPs with lower flash, you can also define any other part of flash for storage. You only have to tell the linker to exclude it from the applciaiton flash.
And ou have to tell the linekr that the interrupt vectors aren't at 0xFF80 anymore but somewhere else. (the copy code contains fixed interrupt vectors that point to a jumptable that is also part of this code, and the jumps utilize the new vector table location - except for the reset vector that of course points to the copy code).

JIS JOHN said:

In the firmware upgrade are you using two separate projects

I have included the bootloader into the project itself. The bootloader won't update itself (jsu tignore the lasr 1kb of the image). The change in the linker script memory configuration ensures that applicaiton and loader are separated adn the loader always ends up at the same place.
This way, I can use the same binary for direct uplao fwith JTAG or for online update.

However, this is not a requirement. The loader contans an interrupt vector table that points to a table of indirect jumps within the loader area. The linke rhas been told to write the applciation interrupt vectors to 0xFBxx (right beneath the laoder area) instead of 0xFFxx. The jumps in the loader area indirectly jump through this moved vector table:
MOV &0xFBxx, PC
This way, the loader area can always stay the same, including the vector table and especially the reset vector (so there won't be a moment where the device wouldn't start due to erasure of the vector table) while all ISRs are properly jumped to (except the program entry, which is of course called by the loader after performing the update check, instead of directly through the reset vector)

0xFB80-0xFBFF - applicaiton interrupt vector table adn end of updated area
0xFC00-0xFCFF - jumps for the forwarded interrupts
0xFD00-0xFF7F - loader code, ends with MOCE &0xFBFE, PC to start the applicaiton
0xFF80-0xFFFD - real vector table, all vectors are pointing to their respective jumps the jumptable.
0xFFFE-0xFFFF - real reset vector, pointing to the start of the loader.