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. > 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. > > 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** > ------------------------------------------------------------------------------ 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
