JMGross <mspgcc <at> grossibaer.de> writes: > > 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 :)
That's a very good idea indeed. I only need a boot copier. For now, the linker file of the main appliatcion was tweaked so that the reset vector points to the start of the bootloader zone. A real issue appears if programming the bootloader after the main application as they each write the same interrupt vector table. Luckily, the bootloader doesn't need any interrupts to function. For now :). > 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. > As I said, seems like a very good idea, but there's one thing I don't understand. Why do you need the 'indirect jumping zone'. Why wouldn't it be possible to program the vector in bootvect to jump directly to the interrupt vector table of the application? Except, of course, the reset vector which will still point to the bootloader. > 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,...) > How do you declare constant blocks in the source file so that they are included 'as they are' in the binary file and then onto the flash. Thank you, Alex > 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 ------------------------------------------------------------------------------ uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
