so, .vectors SHOULD be inside of .text. I do not remember, if it's possible in linker scripts.... maybe, it's ok to create the vector variables within .text section in CRT library, and so consolidate .text ?
2007/11/22, [email protected] <[email protected]>: > > > The thing is, that I usually need to compile a large C code, and you don't > really know where to split it, what to put in .text2, and what to leave in > .text1; the linker has all the information about this stuff. > So it kind of should be done automatically. > > > > > *"Oleg V. Kobrin" <[email protected]>* > Sent by: [email protected] > > 11/22/2007 05:43 PM > Please respond to > "GCC for MSP430 - http://mspgcc.sf.net"; < > [email protected]> > > To > "GCC for MSP430 - http://mspgcc.sf.net"; < > [email protected]> cc > > Subject > Re: [Mspgcc-users] msp430x status > > > > > > > usually, the .text2 section is created there, and some functions is > explicitly placed there using attribute(). > > 2007/11/22, *[email protected]* <[email protected]> <* > [email protected]* <[email protected]>>: > > Thank you for the detailed answer, I'm considering it. > I might only write a seprate program and include it as .word to load the > program. > > I have come up with a problem: I need to address the memory space > correctly. > > The .text section is between 0x3100 and 0xffc0 and the .vectors is betwwen > 0xffc0 and 0xffff > To use all the 116K of the FG4618 the .text should be between 0x3100 and > 0x1c520, but the .vectors should still be where they were, because that's > where they are physically located. > > Any suggestions how to get around this? > Modify somehow the linker script? (Include the .vectors section in the > .text?) > Something else? > > Thanks, > Oszkar > > > > *Chris Liechti <**[email protected]* <[email protected]>*>* > Sent by: > *[email protected]*<[email protected]> > > 11/15/2007 10:52 PM > Please respond to > "GCC for MSP430 - *http://mspgcc.sf.net* <http://mspgcc.sf.net/>" > <*[email protected] > * <[email protected]>> > > > To > "GCC for MSP430 - *http://mspgcc.sf.net* <http://mspgcc.sf.net/>" <* > [email protected]* <[email protected]>> > cc > > Subject > Re: [Mspgcc-users] msp430x status > > > > > > > > * > **[email protected]* <[email protected]> schrieb: > > I'm trying to find a way to be able to upload above that level (I'm > > trying to run msp430-jtag, but can't seem ti succeed). > > the CVS version should be able to write the lower 64kB of a MSP430X. i > tested with FG4619. > > > Any suggestions on how to load/debug code above 64K? > > msp430-jtag with the parallel port JTAG uses "self programming" (because > it's easier to let the msp430 generate the flash clock compared to the > non real-time PC). you'll find the sources in CVS/jtag/funclets. > > once the assembler in binutils is aware of MSP430X instructions it > should be possible to write such a "funclet" that writes memory above > 64kB. > > The other problem is how to get the larger addresses into the tool as > most code assumes 16 bit addresses. maybe i can help there provided > there are example ELF and a43 files with 32 bit (?) addresses. > > Changes are: > - file loader for elf, ti-text, a43 (python code) > - funclet interface. the funclets are patched with start/end addresses > and the data, needs to be adapted > - some address passing functions may limit to 16 bit addresses > - probably something else i don't think of now.. > > i think with this steps we can keep the JTAG access in 16 bits as it is > working now and the modification should be simple (given there are > binaries to play with and the assembler) > > chris > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005.* > **http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/*<http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/> > _______________________________________________ > Mspgcc-users mailing list* > **[email protected]* <[email protected]> > * > **https://lists.sourceforge.net/lists/listinfo/mspgcc-users*<https://lists.sourceforge.net/lists/listinfo/mspgcc-users> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005.* > **http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/*<http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/> > _______________________________________________ > Mspgcc-users mailing list* > **[email protected]* <[email protected]> > * > **https://lists.sourceforge.net/lists/listinfo/mspgcc-users > *<https://lists.sourceforge.net/lists/listinfo/mspgcc-users> > > > > > -- > _____________ > Oleg V. Kobrin > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________ > Mspgcc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Mspgcc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > -- _____________ Oleg V. Kobrin
