Yes, it's doable. I haven't done it myself, so you're mostly on your own, but the approach I'd take is to have a bootloader application with unique vectors, text, and data sections, compiled to an object file. I.e., it would have symbols going into .bldr.vectors, .bld.text, .bld.data, etc. I'd expect to need to use elf editing tools to rename the sections in this object file.
Then I'd build application object files using the standard section names. Finally, I'd like the application with the bootloader using a custom linker script that put the .bldr.* sections in the "right place" (i.e., .bldr.vectors at 0xff80, and its text and data into distinct parts of the flash and ram regions) and the non-.bldr sections in other parts of flash and ram. The result would be a single image combining bootloader and application which could be flashed with mspdebug without having to figure out how to erase only the application parts of the memory, leaving the bootloader. Of course, since this would couple the application to the bootloader it's not clear what value the bootloader has. Presumably you still need to build applications that do not include the bootloader, but you could use the same script for that and just not include the bootloader object file when doing the link. How you get that onto the MCU is a different problem (which presumably involves the ability to tell mspdebug to erase only the application parts of the flash and copy in a new application, leaving the bootloader flash sections untouched). I'm afraid that general idea is the best I can do for you; you'll have to experiment to get a working solution. Peter On Fri, Apr 18, 2014 at 4:27 PM, Tomek Lorek <tlo...@gmail.com> wrote: > 2014-04-18 22:23 GMT+02:00 Peter Bigot <big...@acm.org>: >> Re-reading your original post, I had focused on your last sentence, >> which in context wasn't the right question. >> >> You don't change anything in the boot loader. You replace the >> memory.ld script for applications with one that puts the .vectors >> region somewhere other than 0xff80, and keeps the flash size and >> offset from overlapping the bootloader. The bootloader then copies >> from the application .vectors into RAM. No need to change the main >> linker script at all, just provide a different memory.ld. > > I guess that is the recipe for the vector table stored in RAM > (SYSRIVECT bit of SYSCTL set). I already did this and it works ok, > although I let the application to register its interrupt handlers > itself, the SYSRIVECT is set by the bootloader. > > But still I need to know if it's doable to make the bootloader use > just reset vector and the application to define all interrupts except > reset. It's like to create the application that has no init, I'm ok > with it because I know the bootloader has and expect the bootloader to > be called every time the MCU powers up. > Of course I can program only by bootloader (and then intentionally > skip 0xFFFE address) but I wanted a handy and convenient solution that > could be flashed with mspdebug. > > Thanks for your help! ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
