On Wed, Oct 10, 2012 at 12:11 PM, Valentin Sawadski <valen...@tado.com> wrote: > Hi Peter, > > thanks a lot! I think I now managed to do what I wanted to. All my interrupt > handler and some of data remains in lower memory while the bulk of my > software is in upper memory. > > However one think still puzzles me. When building without -mcode-region=far > and -mdata-region=far it breaks because of some overflow by a couple of > bytes. However -ffunction-section is enabled like you recommended. > If now the code and data region is set to far it works and according to the > dissasembly interrupt handler and some functions regarding startup are being > placed in lower memory. The most of lower memory hower is unused. I guess > that was to be expected if I redirect every non ISR code to far memory. > However how can I avoid having such a big hole in lower memory?
Don't use both -mcode-region=far and -mdata-region=far. That forces those objects into far memory. The default value, or explicit -mcode-region=any, will fill near memory first then overflow into far. How successful this will be depends on the order things are fed to the linker: your problems might recur if the interrupt code, which must be near, is presented only after other stuff has already consumed the available low memory space. Alternatively, put placement attributes on one or two very large functions or objects so they get shoved up into far memory, leaving the rest for default placement. On the other hand, what does it matter if there are holes in low memory? Without link-time optimizations that convert 20-bit functions into 16-bit ones there won't be any performance improvement from putting them there. Peter > > Am I still doing something wrong when invoking MSPGCC? > > msp430-gcc -mmemory-model=large -ffunction-sections -fdata-sections > -mcode-region=far -mdata-region=far -Os -fno-strict-aliasing -Wall > -mmcu=msp430f5335 -MMD -c file.c -o file.o > > msp430-gcc -mmemory-model=large -Wl,-gc-sections -mcode-region=far > -mdata-region=far -mmcu=msp430f5335 file.o -o file > > Thanks a lot, > Valentin > > On Thu, Oct 4, 2012 at 1:29 PM, Peter Bigot <big...@acm.org> wrote: >> >> 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 >> > > > > -- > 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
