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]> Sent by: [email protected] 11/15/2007 10:52 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 [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/ _______________________________________________ Mspgcc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mspgcc-users
