You should do it exactly the other way: put the bootloader to the end of 64k region and move everything else down. The main reason is that each program has its own interrupt vector table. Including its own reset vector. But your bootloader needs to have at least the reset vector pointing to itself. And maybe has own ISRs during the boot process.
So one main requirement for a stable bootloader is that there will be no situation in whcih it wouldn't be called after a reset. It means that you may never ever touch the vector table, not even to update it for the applicaiton. My own approach for this was as follows (note that my 'bootloader' is only a 'boot copier'. The new firmware has been received by the old firmware and stored (with CRC) in a free flash region. The priciple is the same, however, only the bootloader is way smaller this way :) I created three new flash segments. One, bootvect, resides where the original interrupt vector tables was. The old vector table is moved down by 1k (or whatever mutliple of 512 bytes you need) second section is just below and consists of a set of indirect jumps. third section is for the bootloader and below the other two. The bootvect section is filled with references to the jumpsection. One jump per vector. Except the reset vector. The reset vector of course points to the bootloader. So every interrupt except a reset will jump into the jumptable. The jumptable is filled with indirect jumps jumping indirectly on the content of the moved application interrupt vector table. And the bootloader, if it decides that there is nothing to do or everythign is done, jumps indirectly over the reset vector in the 'real' vector table. So after the bootlaoder is installed once, it will never need to erase the real interrupt vector table on 0xffxx. Or parts of itself. In my case, the region from 0xfc00 to 0cffff is never ever touched again. The application is compiled normally. It includes the bootloader, but this is a constant block, so a JTAG update will put it where it belongs. But when the update is sent to the old applciation and stored for update, the bootloader part will be ignored. The application, however, will only occupy the flash from start to 0xfbff. With its vector table ending on 0xfbff (or below, if the bootloader part is larger) 0x5C00-0xFB7F application flash 0xFB80-0xFBFF applcation interrupt vector table 0xFC00-0xFE7F bootloader 0xFE80-0xFF7F jumptable (br &0xFB80; br &0xFB82;...) 0xFF80-0xFFFF 'real' vector table, pointing to bootloader start or jumptable. (0xFE80, 0xFE84, 0xFE88,...) This constellation was build after several discussions in the TI E2E community. And considered the best for failsafe and transparent operation. It has, however, the drawback of 4 additional clock cycles interrupt latency (because of the double-jumping) JMGross ----- Ursprüngliche Nachricht ----- Von: Alex Stefan An: mspgcc-users@lists.sourceforge.net Gesendet am: 06 Aug 2011 00:09:16 Betreff: [Mspgcc-users] Custom linker file Hello, I am working on a custom bootloader. For the time being I am trying to the main code to a higher address and create a custom section to hold the bootloader code. After reading further I concluded that what I need is a separate section, not defining a memory region. But, from there on, everything gets foggy so I would need a little help to point me in the right direction: writing a custom linker file for msp430 and maybe a small example of such a file. ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
