Note that the ISR placement limitation is fundamental to the MSP430 architecture; this is not a limitation of mspgcc.
Clearly something's using up most of low memory, leaving too little room for the data that has to be placed there. Possibly the material in the library is not compiled with large memory model. The warning about conflicting CPUX target flags suggests this. Possibly the material in the library was archived with flags that did not preserve the original sections. When the .any.* sections are translated to .near.* or .far.*, things are generally packed into near flash before far flash. If that's what's happening, there should be a linker flag that would inhibit the section assignment; alternatively, -mcode-region=far might be appropriate. Possibly your interrupt handlers are extremely large and/or have a lot of const data within them (static variables or strings). An effect of the -*-sections flags is that function data is often placed into sections that are in the same region as the function itself. Without seeing more details of what you're doing I can't tell how to fix it, but above are the things you should look into next. You'll want to run: msp430-objdump -t file on each of the object files and archives to see what section things are assigned to. Peter On Thu, Oct 4, 2012 at 5:04 AM, Valentin Sawadski <valen...@tado.com> wrote: > Hi Peter, > > On Wed, Oct 3, 2012 at 7:55 PM, Peter Bigot <big...@acm.org> wrote: >> >> On Wed, Oct 3, 2012 at 12:26 PM, Valentin Sawadski <valen...@tado.com> >> wrote: >> > Hi Peter, >> > >> > thanks for your quick response. Does this mean that I can not have >> > Interrupt >> > handlers in far memory? >> >> Correct, you cannot have interrupt handlers in far memory. You can >> call far memory from a handler, but the handler itself will be placed >> in near memory. >> >> > If so, what's the point of the -misr20 flag? >> >> -msr20 saves registers as 20-bit values in all calls, which increases >> required stack space. If functions do not have live 20-bit register >> values when they call subroutines, the functions they call do not need >> to save 20-bit registers. However, such functions might have 20-bit >> values in registers temporarily while computing expressions inside the >> function. Since interrupts can occur asynchronously, -misr20 >> specifies that interrupt handlers should save registers to 20-bits >> even when other functions don't need to. > > > Thanks for the clarification. That kinda changes what I had planned with the > ISRs but it's good to know. :-) > >> >> > Also >> > what if I want to use the Vector-Table redirect feature of the MSP430X >> > will >> > it then be possible to place interrupts in far memory? >> >> No, because the fact that SYSRIVECT places the interrupt vector at the >> top of RAM (which is in low memory) does not change the fact that the >> entries are 16 bit and that the handlers must also be in low memory. >> >> > Regarding the -ffunction-sections flag. No I did not use this. I was >> > under >> > the impression that -mmemory-model=large sets all the flags where >> > appropriate. >> >> It sets the target-specific flags that are related to the memory >> model. It does not set generic gcc or linker flags. >> >> > But I guess it only changes the pointers, not the linking, >> > right? However, every combination of -ffunction and -mmemory-model I >> > tried >> > resulted in an error with LD complaining about conflicting directives. >> > Can you please provide me a sample configuration for compiling linking >> > so >> > that code and data will be placed in near and far memory? >> >> I don't have a vetted example immediately to hand; all the test cases >> are scripts that create the argument lists at runtime. You should be >> able to use: >> >> -mmemory-model=large -Os -ffunction-sections -fdata-sections >> >> in CFLAGS and add >> >> -Wl,-gc-sections >> >> in LDFLAGS. >> >> > > > Still I seem to be missing something, here's my complete debug output. > > msp430-gcc -mmemory-model=large -Os -ffunction-sections -fdata-sections -Os > -fno-strict-aliasing -ffunction-sections -Wall -mmcu=msp430f5335 -I. -MMD > -c ../../file.c -o obj/file.o > > msp430-gcc -Wl,-gc-sections -mmcu=msp430f5335 -Wl,-Map=program.map > -Wl,--gc-sections,--undefined=_reset_vector__,--undefined=InterruptVectors,--undefined=_copy_data_init__,--undefined=_clear_bss_init__,--undefined=_end_of_init__ > main.co obj/file1.o obj/file2.o obj/file3.o library.a -o main.bin > > What I then receive is this: > > /opt/compiler/mspgcc-20120911/lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: > Warning: Conflicting CPUX target flags > /opt/compiler/mspgcc-20120911/lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: > node-main.tado-box section `.data' will not fit in region `rom' > /opt/compiler/mspgcc-20120911/lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: > section .vectors loaded at [000000000000ff80,000000000000ffff] overlaps > section .data loaded at [000000000000ff7e,0000000000010157] > /opt/compiler/mspgcc-20120911/lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: > region `rom' overflowed by 472 bytes > > >> >> > >> > Best Regards, >> > Valentin >> > >> > On Wed, Oct 3, 2012 at 5:06 PM, Peter Bigot <big...@acm.org> wrote: >> >> >> >> Even for MSP430X, the vector table is placed in near memory (at an >> >> address that is specific to the MCU), and the pointers in the table >> >> must be to code located in near memory. The compiler automatically >> >> adds c16 to any function that has the interrupt attribute, so that >> >> these requirements are met. If you have interrupts, you will always >> >> have some code in near text. >> >> >> >> >From what I see below I'm guessing that you are not using >> >> -ffunction-sections and -fdata-sections when compiling, and/or >> >> -Wl,-gc-sections when linking. If you do that, then in large memory >> >> mode each allocatable object gets placed in its own section, and the >> >> linker should put some in low memory and some in high, so the >> >> -mcode-region and -mdata-region aren't necessary. However, if you >> >> don't have those section flags then everything that is text (data) >> >> gets put into one big blob, and things are likely to overflow. >> >> >> >> >> >> >> >> http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Gcc47:20-Bit_Design#Object_Placement >> >> has some discussion of those flags. >> >> >> >> Peter >> >> >> >> On Wed, Oct 3, 2012 at 9:01 AM, Valentin Sawadski <valen...@tado.com> >> >> wrote: >> >> > Hi everybody, >> >> > >> >> > I'm trying to get a nontrivial program working with the 20bit MSP430X >> >> > extension. While lots of it is working perfectly I'm currently >> >> > confused >> >> > with the size of my vector table. >> >> > I'm compiling and linking with -mmemory-model=large >> >> > -mcode-region=far. >> >> > As I >> >> > understand it any code should then be placed in far memory. But when >> >> > Programming the device I see 128bytes written to 0xff80 so I'm >> >> > guessing >> >> > my >> >> > vector table is still using the 16bit pointers. >> >> > >> >> > If however I remote the -mcode-region=far I receive the following >> >> > errors: >> >> > >> >> > >> >> > >> >> > /opt/compiler/mspgcc-20120911/lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: >> >> > node-main.tado-box section `.rodata' will not fit in region `rom' >> >> > >> >> > >> >> > /opt/compiler/mspgcc-20120911/lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: >> >> > section .vectors loaded at [000000000000ff80,000000000000ffff] >> >> > overlaps >> >> > section .rodata loaded at [000000000000f824,000000000000ff81] >> >> > >> >> > >> >> > /opt/compiler/mspgcc-20120911/lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: >> >> > section .data loaded at [000000000000ff82,000000000001015b] overlaps >> >> > section .vectors loaded at [000000000000ff80,000000000000ffff] >> >> > >> >> > >> >> > /opt/compiler/mspgcc-20120911/lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: >> >> > section .far.text loaded at [0000000000010000,0000000000019a0b] >> >> > overlaps >> >> > section .data loaded at [000000000000ff82,000000000001015b] >> >> > >> >> > >> >> > /opt/compiler/mspgcc-20120911/lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: >> >> > region `rom' overflowed by 476 bytes >> >> > collect2: error: ld returned 1 exit status >> >> > make: *** [node-main.tado-box] Error 1 >> >> > >> >> > Can somebody shed some light into that as I'm not sure I understand >> >> > the >> >> > consequences of 20bit pointers and the compiler switches, even after >> >> > reading the very helpful wiki page on them ( >> >> > >> >> > >> >> > http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Gcc47:20-Bit_Design >> >> > ) >> >> > >> >> > Best Regards, >> >> > >> >> > -- >> >> > Valentin Sawadski >> >> > Head of Embedded Hard- and Software >> >> > >> >> > Tel.: +49 - (0) 89 - 416 15 66 4 - 5 >> >> > Fax: +49 - (0) 89 - 416 15 66 4 - 9 >> >> > Mobil: +49 - (0) 162 - 460 163 4 >> >> > www.tado.com >> >> > www.facebook.com/tado.com >> >> > www.twitter.com/tado >> >> > >> >> > tado.com ist ein Angebot der tado° GmbH >> >> > >> >> > tado° GmbH | Kochelseestrasse 8-10 | 81371 München >> >> > Geschäftsführer: Christian Deilmann | Johannes Schwarz | Leopold v. >> >> > Bismarck >> >> > Eingetragen beim Amtsgericht München, HRB 194769 B | Ust.-ID Nr. DE >> >> > 280012558 >> >> > >> >> > VERTRAULICHKEITSHINWEIS: Diese Nachricht ist vertraulich. Sie darf >> >> > ausschließlich durch den vorgesehenen Empfänger und Adressaten >> >> > gelesen, kopiert oder genutzt werden. Sollten Sie diese Nachricht >> >> > versehentlich erhalten haben, bitten wir, den Absender (durch >> >> > Antwort-E-Mail) hiervon unverzüglich zu informieren und die Nachricht >> >> > zu löschen. Jede Nutzung oder Weitergabe des Inhalts dieser Nachricht >> >> > ist unzulässig. >> >> > >> >> > CONFIDENTIALITY NOTICE: This message (including any attachments) is >> >> > confidential and may be privileged. It may be read, copied and used >> >> > only by the intended recipient. If you have received it in error >> >> > please contact the sender (by return e-mail) immediately and delete >> >> > this message. Any unauthorized use or dissemination of this message >> >> > in >> >> > whole or in part is strictly prohibited. >> >> > >> >> > **Please consider the environment before printing this e-mail** >> >> > >> >> > >> >> > >> >> > ------------------------------------------------------------------------------ >> >> > Don't let slow site performance ruin your business. Deploy New Relic >> >> > APM >> >> > Deploy New Relic app performance management and know exactly >> >> > what is happening inside your Ruby, Python, PHP, Java, and .NET app >> >> > Try New Relic at no cost today and get our sweet Data Nerd shirt too! >> >> > http://p.sf.net/sfu/newrelic-dev2dev >> >> > _______________________________________________ >> >> > Mspgcc-users mailing list >> >> > Mspgcc-users@lists.sourceforge.net >> >> > https://lists.sourceforge.net/lists/listinfo/mspgcc-users >> >> > >> >> >> > >> > >> > >> > -- >> > Valentin Sawadski >> > Head of Embedded Hard- and Software >> > >> > Tel.: +49 - (0) 89 - 416 15 66 4 - 5 >> > Fax: +49 - (0) 89 - 416 15 66 4 - 9 >> > Mobil: +49 - (0) 162 - 460 163 4 >> > www.tado.com >> > www.facebook.com/tado.com >> > www.twitter.com/tado >> > >> > tado.com ist ein Angebot der tado° GmbH >> > >> > tado° GmbH | Kochelseestrasse 8-10 | 81371 München >> > Geschäftsführer: Christian Deilmann | Johannes Schwarz | Leopold v. >> > Bismarck >> > Eingetragen beim Amtsgericht München, HRB 194769 B | Ust.-ID Nr. DE >> > 280012558 >> > >> > VERTRAULICHKEITSHINWEIS: Diese Nachricht ist vertraulich. Sie darf >> > ausschließlich durch den vorgesehenen Empfänger und Adressaten >> > gelesen, kopiert oder genutzt werden. Sollten Sie diese Nachricht >> > versehentlich erhalten haben, bitten wir, den Absender (durch >> > Antwort-E-Mail) hiervon unverzüglich zu informieren und die Nachricht >> > zu löschen. Jede Nutzung oder Weitergabe des Inhalts dieser Nachricht >> > ist unzulässig. >> > >> > CONFIDENTIALITY NOTICE: This message (including any attachments) is >> > confidential and may be privileged. It may be read, copied and used >> > only by the intended recipient. If you have received it in error >> > please contact the sender (by return e-mail) immediately and delete >> > this message. Any unauthorized use or dissemination of this message in >> > whole or in part is strictly prohibited. >> > >> > **Please consider the environment before printing this e-mail** >> > >> > > > > -- > Valentin Sawadski > Head of Embedded Hard- and Software > > Tel.: +49 - (0) 89 - 416 15 66 4 - 5 > Fax: +49 - (0) 89 - 416 15 66 4 - 9 > Mobil: +49 - (0) 162 - 460 163 4 > www.tado.com > www.facebook.com/tado.com > www.twitter.com/tado > > tado.com ist ein Angebot der tado° GmbH > > tado° GmbH | Kochelseestrasse 8-10 | 81371 München > Geschäftsführer: Christian Deilmann | Johannes Schwarz | Leopold v. Bismarck > Eingetragen beim Amtsgericht München, HRB 194769 B | Ust.-ID Nr. DE > 280012558 > > VERTRAULICHKEITSHINWEIS: Diese Nachricht ist vertraulich. Sie darf > ausschließlich durch den vorgesehenen Empfänger und Adressaten > gelesen, kopiert oder genutzt werden. Sollten Sie diese Nachricht > versehentlich erhalten haben, bitten wir, den Absender (durch > Antwort-E-Mail) hiervon unverzüglich zu informieren und die Nachricht > zu löschen. Jede Nutzung oder Weitergabe des Inhalts dieser Nachricht > ist unzulässig. > > CONFIDENTIALITY NOTICE: This message (including any attachments) is > confidential and may be privileged. It may be read, copied and used > only by the intended recipient. If you have received it in error > please contact the sender (by return e-mail) immediately and delete > this message. Any unauthorized use or dissemination of this message in > whole or in part is strictly prohibited. > > **Please consider the environment before printing this e-mail** > ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
