From: Eric D. <ci...@gm...> - 2013-02-24 15:48:30
|
cool that gives me enough info to duplicate I'll add it to my list can you also file an issue on the tp-freeforall github issues page? From cPhone On Feb 24, 2013, at 7:40 AM, Martin Zoller <mar...@ti...> wrote: > I'm using the tp-freeforall/prod repository. To avoid any doubt I retested it on a new clone of the repository. > To the Makefile of Blink I added: > CFLAGS += -ffunction-sections -fdata-sections > > As far as I understand, the problem is caused by the MSP430REG_NORACE_EXPAND macro in msp430hardware.h: It generates asm statements which reference a memory address, rather than a symbol. Unfortunately I don't know enough about macros to be able to fix this right now. > > However I've noticed that only -fdata-sections is troublesome, and -ffunction-sections works fine. So by using > CFLAGS += -Wl,--section-start=.text=0xBC00 > CFLAGS += -ffunction-sections -mdata-region=far > LDFLAGS += -Wl,--gc-sections > I can achieve my goal of splitting the app into a "near" and a "far" part without wasting memory in between. > Of course this only works as long as the "far" part is larger than the data section. > Note that my app's "near" part starts at 0xBC00; the lower 30k of flash are used by a bootloader and a second app. > > > Martin > > On 02/23/2013 12:57 AM, Eric Decker wrote: >> >> >> I've built Blink for near memory using 4.7 without problem for a 5437a. I've also build Blink for the telosb without problems. >> >> I haven't tried different memory models. >> >> Not sure what exactly martin is using... ie. what source tree. >> >> The current new msp430 core code can be obtained via git from https://github.com/tp-freeforall/prod >> >> On Fri, Feb 22, 2013 at 9:58 AM, Peter Bigot <bi...@ac...> wrote: >> Figure out why those asm statements are getting emitted and replace it with >> something that references a linker symbol like __P3OUT and __P4OUT. >> >> I believe Eric Decker was looking into reworking the MSP430 port support in >> TinyOS to fix this. >> >> Peter >> >> On Fri, Feb 22, 2013 at 11:49 AM, Martin Zoller >> <mar...@ti...>wrote: >> >> > Hi, >> > I'm experimenting with the -ffunction-sections and -fdata-sections >> > parameters of mspgcc. >> > The goal is to split a TinyOS application between near and far flash >> > memory using the large memory model. If I do this without special compile >> > parameters, only a small amount of code ends up in the .text section >> > (presumably the ISRs), and the rest is put in .far.text, rather than >> > filling up .text first. >> > >> > Now unfortunately -ffunction-sections and -fdata-sections seem to be >> > broken in mspgcc 4.7.0 20120911. >> > For example, if I compile the TinyOS Blink application for telosb with >> > them, I get: >> > >> > /tmp/ccb7btaA.s:1220: Error: Missing symbol name in directive >> > /tmp/ccb7btaA.s:1220: Error: junk at end of line, first unrecognized >> > character is `x' >> > /tmp/ccb7btaA.s:1221: Error: expected comma after name `' in .size >> > directive >> > /tmp/ccb7btaA.s:1222: Error: junk at end of line, first unrecognized >> > character is `0' >> > /tmp/ccb7btaA.s:1224: Error: Missing symbol name in directive >> > /tmp/ccb7btaA.s:1224: Error: junk at end of line, first unrecognized >> > character is `x' >> > /tmp/ccb7btaA.s:1225: Error: expected comma after name `' in .size >> > directive >> > /tmp/ccb7btaA.s:1226: Error: junk at end of line, first unrecognized >> > character is `0' >> > /tmp/ccb7btaA.s:1229: Error: Missing symbol name in directive >> > ... and lots more of those. >> > >> > The problem is that the assembler code contains addresses instead of >> > symbol names: >> > .LIRD0: >> > .size main, .-main >> > .section .bss.0x0019,"aw",@nobits >> > .type 0x0019, @object ;Line 1220 >> > .size 0x0019, 1 >> > 0x0019: >> > .zero 1 >> > .type 0x0019, @object >> > .size 0x0019, 1 ;Line 1225 >> > 0x0019: >> > .zero 1 >> > .section .bss.0x001D,"aw",@nobits >> > .type 0x001D, @object >> > .size 0x001D, 1 ;Line 1230 >> > >> > I tried this without any special options, i.e. with memory model "none". >> > It compiles fine on mspgcc 4.6.3 20120406. >> > The thread at [1] mentions the same issue, but without a solution. And in >> > [2] Peter suggests the problem is caused by the asm statement, which is >> > treated differently by gcc 4.7. >> > However, the code above seems to correspond to the following declarations >> > in app.c (each appearing in several functions): >> > >> > static volatile uint8_t r __asm("0x0019"); >> > static volatile uint8_t r __asm("0x001D"); >> > >> > So they are already static. >> > Is there a known workaround for this issue? >> > >> > >> > Thanks, >> > Martin >> > >> > [1] - http://lists.gnu.org/archive/**html/bug-binutils/2012-10/** >> > msg00111.html<http://lists.gnu.org/archive/html/bug-binutils/2012-10/msg00111.html> >> > [2] - http://sourceforge.net/**mailarchive/forum.php?thread_**name=** >> > CAPOJ94M1tobePYig6XdJjwTVamFj1**DC2uDFyUu%3DZChzFHBApUw%** >> > 40mail.gmail.com&forum_name=**mspgcc-users<http://sourceforge.net/mailarchive/forum.php?thread_name=CAPOJ94M1tobePYig6XdJjwTVamFj1DC2uDFyUu%3DZChzFHBApUw%40mail.gmail.com&forum_name=mspgcc-users> >> > >> > -- >> > >> > Martin Zoller ? Tinynode <http://www.tinynode.com/> ? System Architect ? >> > Lausanne ? D: +41 21 510 11 81 ? F: +41 21 510 11 71 ? >> > mar...@ti... <mailto:martin.zoller@**tinynode.com<mar...@ti...> >> > > >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > Everyone hates slow websites. So do we. >> > Make your web apps faster with AppDynamics >> > Download AppDynamics Lite for free today: >> > http://p.sf.net/sfu/appdyn_d2d_feb >> > _______________________________________________ >> > Mspgcc-users mailing list >> > Msp...@li... >> > https://lists.sourceforge.net/lists/listinfo/mspgcc-users >> > >> > >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> _______________________________________________ >> Mspgcc-users mailing list >> Msp...@li... >> https://lists.sourceforge.net/lists/listinfo/mspgcc-users >> >> >> >> >> -- >> Eric B. Decker >> Senior (over 50 :-) Researcher >> > > > -- > Martin Zoller ● Tinynode ● System Architect ● Lausanne ● D: +41 21 510 11 81 ● F: +41 21 510 11 71 ● mar...@ti... > > New postal address from 12/15/2012: Tinynode SA, Boulevard de Grancy 19A, 1006 Lausanne |