The main problem will be a bit different here: if you'll put all the code into a library, and will assume that firmware calls user apps, you firmcode will never be linked, unless user app will call it. Even more -- putting interrupt service routines to the library will result in that ISRs will never linked. This problem discussed in the list a while ago. So, look through the list. Another thing is that you do not have to use 'as' and 'ld' for most purposes -- you miss some important defines. Putting a bunch of code and vars at the specific address is not a problem as well -- define sections, set up their addresses, etc... read docs.
If you get startup from libgcc and crtXXXXX, you do not have to do anything with user and firmare initialized data. they will be linked properly. there are no bugs (as far as i can see) in linker scripts. the script you need is '.x'. .xr -- a script w/o relocations (mostly for libraries) .xu -- w/o relocs, creates constructors .xn -- mix text and data on the same page .xbn -- the same as above w/o alignment cheers, ~d On Wednesday 08 October 2003 17:23, Bjoern Lichtblau wrote: > Hi, > > what we want to do is flash reprogramming (the code itself) > via a radio link. We've already completed it in a very simple > way by putting essential functions for the flash reprogramming > (reading from eeprom, writing to flash) in a special segment > as described in the faq and saying that these functions should > never change, and it worked well. > > What we like now to do, is seperate our complete software into > two parts: > 1. Something like a "firmware", it should have the startup code, > the main-loop, "device drivers" and most important: the code > for flash reprogramming > 2. the "user application", this gets one initial call from the firmware > to set up callbacks for events etc..., and should be replacable > by any other user app which was linked against the same firmware. > > The goal of this would be, that if the user application isn't really > hostile, we have the chance to flash a new user application onto the > board even if the old one crashed the board (watchdog would notice this > and therefor never init the buggy user app again, > firmware is then waiting for a new version and all code neccessary for > flash reprogramming via radio is still fine). > > I imagined i would have to do the following steps after seperating > our code: > 1. compile all firmware files into .o-files and stuff them together > via msp430-ar. > 2. compile and link the user app against the firmware, use a linker file > to make sure that all firmware code is in one place in the flash and > user app is at another (the same for their data in the ram) > > Problems/Questions: > 1. The init call from the firmware to the userapp is a little problem > as i compile the firmware before the userapp. I would do an inline > assembler call to a fixed place for that and the userapp has to put > its init function there (via new section and defining start address). > Can this made be simpler? > Do i get problems here with optimized out dead code ? > All other calls from userapp to firmware should be no problem as the > firmware is fixed and always in the same place, userapp is linked > against the firmware. > > 2. Can i specify in the linker script, that all code from my firmware > should be placed first, then all code from the user app; and the > same with the data in the ram, which should als not be intermixed?! > > 3. What should i do with the startup code ? If i do it that way, what > happens to initialized variables? I think the startup code wont > handle two data segments, one from the firmware and one from the > user app... the simplest would be to abandon the startup code > and initialize all global vars in functions?! > > 4. I already started what i described above, seperated all source files > and compiled the firmware into object-files and then put them together > with ar. Fine. > Then i tried to compile and link the userapp with the firmware. First > i simply tried to use my libfirmware.a as an input file, that brought > linker errors to all my functions defined in the firmware. Then i tried > with the -l switch, and i nearly got the same effect. > Is there any difference? > > It also told me: > In function `_reset_vector__': : undefined reference to `main' > As i described in 3 i expected startup code to be a problem > (for another reason), so i replaced it by myself as described in > the documentation, just a branch to main. > After that, nearly all functions could be linked. Comments on that? > > 5. One function still couldn't be linked.. the reason seems to > be that it never gets called by the firmware itself. So i added > a dummy call and voila it could be linked, so this seems to be a > problem with optimizing dead code ?! ( Not really, as i saw the > function in both cases in the assembler listing????) > Anyway, how do i tag functions so this wont happen, it > was already volatile. > > 5. What are all the names in the linker file beginning with rel and rela!? > And whats the difference between .x .xr .xu .xn .xbn ?! > > Sorry for this really long text ;), i hope i'll get at least some clues > to go further, thanks in advance, > Björn Lichtblau > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Mspgcc-users mailing list > Mspgcc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- /***************************************************************** ("`-''-/").___..--''"`-._ (\ Dimmy the Wild UA1ACZ `6_ 6 ) `-. ( ).`-.__.`) State Polytechnical Univ. (_Y_.)' ._ ) `._ `. ``-..-' Radio-Physics Departament _..`--'_..-_/ /--'_.' ,' Saint Petersburg, Russia (il),-'' (li),' ((!.-' +7 (812) 5403923, 5585314 *****************************************************************/
