Hi Carl, you already noticed the FARTEXT section.
The problem with MSPs is that the interrupt vectors are ALWAYS at the end of the first 64KB address space. This is because the processor core has to start at a certain, never changing point. There are some processors where code execution always starts at address0 (hardcoded reset vector) and the location of the vector table is software configurable. usually these devices have a separate address space for code and ram + I/O (Harvard-architecture). There you have 64K ram+I/O space and another 64K program space. (on the ATMega 128 even 128K flash as the 16bit code addresses are word addresses to 16-bit wide flash) But that's a different thing. So on MSP devices the normal TEXT segment ends below the vector table. No matter how much FLASH your MSP might have in total. Additionally, all addresses in your code are usually represented by a 16 bit address vector. So it is impossible to access any address above 64k with standard instructions. (and other than with the A20 gate on PCs, even using indexed register access won't work on the MSP). For all devices with more than 64K usable address range, TI has introduced the MSP430X instruction set. It is backwards compatible to the standard instruction set, so any program using standard instructions will run on an MSP430X device. But any FLASH above 64K is only accessible using the new MSP430X instructions. These instructions use some tricks to extend the normal call/ret instructions by some additional bits. Tere are additional commands for data acces too and much more. Back to your problem: Currently, FARTEXT is supported by the linker but not by the standard compiler (main branch). There is an MSP430X branch of MSPGCC which is intended to support the MSP430X command set. But it is still under development and there are no library version which support the far calls and far pointers properly. There is a way to use the FARTEXT segment even with the non-X branch. You can place large tables or string constants into the FAR text segment and use some hand-crafted assembly code to retrieve the data. (for the string constants, they have to be copied to the lower 64K before using them, as e.g. the printf function in the library does not know about far data) I too use (well, did some testing with) a processor with more than 64K address range (the 5438 with 256KB Flash). But I use the main branch and do not use the additional flash (the I/O is why I will use this one for future projects). Then everything is fine without the compiler need to know about the MSP430X command set. Maybe someone will provide a changed linker script that puts the data for variable init (_edata) into FARTEXT area and changes the reset function to init RAM from there. It would free some flash while being 100% compatible. Anyways, the compiler does not know at all about segment sizes. It might only complain if one compilation block (code in one single C file) exceeds 64K. It's the linker which notices the actual size of each section (as used by several code blocks together) and its absolute address and maximum size (and therefore the overlap). JMGross ----- Ursprüngliche Nachricht ----- Von: Carl An: [email protected] Gesendet am: 09.Januar.2010 19:58:03 Betreff: [Mspgcc-users] section .text will not fit in region text Hello, I'm using mspgcc4 v4.4.2 tools and I'm running into the following error: msp430-ld: bin/a.elf section .text will not fit in region text msp430-ld: section .vectors [0000ffc0 -> 0000ffff] overlaps section .text [00003100 -> 000105f5] msp430-ld: region text overflowed by 1776 bytes make: *** [bin/a.elf] Error 1 Now I understand this is telling me my code size is too big. What I don't understand is why the vectors region is at 0x0000ffc0 and my text region is limited to 0xcec0 (52928) bytes. I'm using a msp430x2618 which has 116k of flash. So I would expect my allowable text region to be closer to 116k rather than the ~52k. What am I missing here? Thanks, Carl
