From lpbrais at bitwrangler.ca Thu Jan 10 18:29:32 2013 From: lpbrais at bitwrangler.ca (Louis-Philippe Brais) Date: Thu, 10 Jan 2013 13:29:32 -0500 Subject: [arm-gnu] Stellaris Non-Word-Aligned Write to SRAM Erratum Message-ID: Hi all, The latest errata for Texas Instruments' Cortex-M3 family, updated last October [1], contains a disturbing new problem triggered by non-word-aligned writes to SRAM. This is the kind of errata that is effectively addressed with a compiler work-around. FWIW, it has already been addressed by a popular commercial toolchain vendor [2]. I was wondering if the GCC ARM maintainers were aware of this bug, and if somebody implemented or was working on a compiler work-around for this problem. I had a look at recent discussions and patches on the GCC mailing lists, but could not find anything. I'm looking for something along the lines of the -mfix-cortex-m3-ldrd fix, but for that new alignment write erratum. [1] http://www.ti.com/lit/er/spmz642b/spmz642b.pdf [2] http://netstorage.iar.com/SuppDB/Public/UPDINFO/007040/arm/doc/infocenter/iccarm.ENU.html Thanks for your attention, LP Brais From bob.brusa at gmail.com Thu Jan 10 20:42:54 2013 From: bob.brusa at gmail.com (Bob Brusa) Date: Thu, 10 Jan 2013 19:42:54 -0100 Subject: [arm-gnu] large footprint when building with CS-lite toolchain Message-ID: Hi, I am using the toolchain that came with eCos3.0 for a AT91Sam7s-based platform. Now I upgraded to the most recent code sourcery lite version (4.7.2) and find, that the program requires much more memory (although I still use the eCos-library built with the old eCos3.0-toolchain). The message I get is shown below: arm-none-eabi-g++ -nostdlib "-LC:\\Projekte\\TDSsw\\libs\\**tds_lib_12_install\\lib" "-T..\\tds_1.ld" -Xlinker -Map -Xlinker tds_4_1.Map -o tds_4_1 util.o usbs_at91.o usbs.o usb_cdc.o uart_dma.o tds_sm.o tds_res.o tds_hif.o tds_execs.o tds_defs.o tds.o sensio.o rombuf.o pa.o help.o eeprom.o c:/osy/codesourcery/**sourcerycodebench_lite_for_**arm_eabi/bin/ ../lib/gcc/arm-**none-eabi/4.7.2/../../../../**arm-none-eabi/bin/ld.exe: address 0x142386 of tds_4_1 section `.rodata' is not within region `rom' c:/osy/codesourcery/**sourcerycodebench_lite_for_**arm_eabi/bin/ ../lib/gcc/arm-**none-eabi/4.7.2/../../../../**arm-none-eabi/bin/ld.exe: address 0x142386 of tds_4_1 section `.rodata' is not within region `rom' c:/osy/codesourcery/**sourcerycodebench_lite_for_**arm_eabi/bin/ ../lib/gcc/arm-**none-eabi/4.7.2/../../../../**arm-none-eabi/bin/ld.exe: address 0x142386 of tds_4_1 section `.rodata' is not within region `rom' collect2.exe: error: ld returned 1 exit status The footprint is almost 20% bigger and the program no longer fits into the flash of the uP. Do I miss something? Let me add, that the previous version (4.6.3) of CS-lite did not produce a footprint that was much different of the one produced by the eCos3.0-toolchain. Thanks for advice and regards - Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: From grant at frogparking.com Sun Jan 13 23:15:20 2013 From: grant at frogparking.com (Grant Ramsay) Date: Mon, 14 Jan 2013 12:15:20 +1300 Subject: [arm-gnu] Hosting warings from sscanf Message-ID: Hi, I have attached a small project that can be built on windows by running build.bat with the correct tool chain installed at this directory "$(ProgramFiles)/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_EABI" Change attachment extension from .zzz to .zip #include int main(void) { sscanf("str1", "str2"); } The line "sscanf("str1", "str2");" seems to give me 4 warnings: libcs3unhosted.a(unhosted-_close.o): warning: IO function '_close' used Similar warnings from _lseek, _read and _write I am looking to try to understand and remove these warnings, Any help would be much appreciated Thanks, Grant -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: warningTest.zzz Type: application/x-zip-compressed Size: 1427816 bytes Desc: not available URL: From joey.ye.cc at gmail.com Wed Jan 16 07:14:44 2013 From: joey.ye.cc at gmail.com (Ye Joey) Date: Wed, 16 Jan 2013 15:14:44 +0800 Subject: [arm-gnu] Stellaris Non-Word-Aligned Write to SRAM Erratum In-Reply-To: References: Message-ID: On Fri, Jan 11, 2013 at 2:29 AM, Louis-Philippe Brais wrote: > Hi all, > > The latest errata for Texas Instruments' Cortex-M3 family, updated > last October [1], contains a disturbing new problem triggered by > non-word-aligned writes to SRAM. This is the kind of errata that is > effectively addressed with a compiler work-around. FWIW, it has > already been addressed by a popular commercial toolchain vendor [2]. I > was wondering if the GCC ARM maintainers were aware of this bug, and > if somebody implemented or was working on a compiler work-around for > this problem. I had a look at recent discussions and patches on the > GCC mailing lists, but could not find anything. I'm looking for > something along the lines of the -mfix-cortex-m3-ldrd fix, but for > that new alignment write erratum. > > [1] http://www.ti.com/lit/er/spmz642b/spmz642b.pdf > [2] http://netstorage.iar.com/SuppDB/Public/UPDINFO/007040/arm/doc/infocenter/iccarm.ENU.html > > Thanks for your attention, > LP Brais I don't see any patch for this erratum. It should be a new option rather than -mfix-cortex-m3-ldrd. - Joey From g4 at novadsp.com Mon Jan 28 18:57:11 2013 From: g4 at novadsp.com (g4 at novadsp.com) Date: Mon, 28 Jan 2013 18:57:11 +0000 Subject: [arm-gnu] .map file analysis? Message-ID: <5106CA07.9050507@novadsp.com> Google inconclusive on this one. I'm wondering if there is a tool that will summarise segment usage and make it slightly easier to determine what to jettison when my binary gets too large to load and run. Something as simple that outputs a CSV to view in Excel would do ... And is there a definitive reference/spec for the generic GCC linker .map file in case i have to roll my own? I'm using Rowley Crossworks ARM edition fro this gig but I don't think that should make any difference (?) Thx++ Jerry. From list-bastian.schick at sciopta.com Tue Jan 29 06:57:13 2013 From: list-bastian.schick at sciopta.com (42Bastian) Date: Tue, 29 Jan 2013 07:57:13 +0100 Subject: [arm-gnu] CPU support for prof. CodeBench Message-ID: <510772C9.60001@sciopta.com> Hi, I noticed that the prof. CodeBench does not support TMS570 (big-endian) and also not the FPU in Cortex-R4F and Cortex-M4F (according this list: http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/platforms/arm-eabi ) Is this right? Cheers, -- 42Bastian + | http://www.sciopta.com | Fastest direct message passing kernel. | IEC61508 certified. + From martin.velek at gmail.com Tue Jan 29 12:06:11 2013 From: martin.velek at gmail.com (Martin Velek) Date: Tue, 29 Jan 2013 13:06:11 +0100 Subject: [arm-gnu] ffunction-sections and linker script input section bug? Message-ID: Hello, I am using NXP LPC2478 with connected ext. NOR flash 16MB for storing code of huge libraries. The LPC2478 contains 512KB flash "onboard". My idea was to divide the frequently running code into internal flash, the rest into ext. NOR flash. I did not want to set attribute to every function, so that I have created a main program and a static library. my linker script contains: MEMORY { rom (rx) : ORIGIN = 0x0, LENGTH = 504K ram (rwx) : ORIGIN = 0x40000000, LENGTH = 64K extnor (rx) : ORIGIN = 0x80000000, LENGTH = 16M } .text : { .... *(EXCLUDE_FILE (*liblibrary.a:) .text .text.* .gnu.linkonce.t.*) .... } ..cs3.extnor : ALIGN (8) { ... *liblibrary.a:(.text .text.* .gnu.linkonce.t.*) ... . = ALIGN (8); } >extnor It works as expected (code from the library is placed from 0x80000000) until I compile the library with -ffunction-sections. Thereafter the linker ignores input section .cs3.extnor and places everything into .text. Is it a bug or I have misunderstood documentation? Best Regards, Martin Velek P.S. I have tried the latest Codebench (trial) for reproducing the issue. There are two projects, library - static library, testFS - main program. Both contain two configuration - DebugOK and DebugNOT_OK. You can the check function placement from Debug[OK|NOT_OK]/testFS.map. If you recreate the board, you will lost the content. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FStest.tar.gz Type: application/x-gzip Size: 9773 bytes Desc: not available URL: From martin.velek at gmail.com Wed Jan 30 09:57:43 2013 From: martin.velek at gmail.com (Martin Velek) Date: Wed, 30 Jan 2013 10:57:43 +0100 Subject: [arm-gnu] ffunction-sections and linker script input section bug? In-Reply-To: References: Message-ID: Hello, problem solved. EXCLUDE_FILE is relevant only to the closest input section. I had to modify it in this way: *(EXCLUDE_FILE (*liblibrary.a:) .text EXCLUDE_FILE (*liblibrary.a:) .text.* EXCLUDE_FILE (*liblibrary.a:) .gnu.linkonce.t.*) Best Martin On Tue, Jan 29, 2013 at 1:06 PM, Martin Velek wrote: > Hello, > > I am using NXP LPC2478 with connected ext. NOR flash 16MB for storing > code of huge libraries. The LPC2478 contains 512KB flash "onboard". My idea > was to divide the frequently running code into internal flash, the rest > into ext. NOR flash. I did not want to set attribute to every function, so > that I have created a main program and a static library. > > my linker script contains: > > MEMORY > { > rom (rx) : ORIGIN = 0x0, LENGTH = 504K > ram (rwx) : ORIGIN = 0x40000000, LENGTH = 64K > extnor (rx) : ORIGIN = 0x80000000, LENGTH = 16M > } > > .text : > { > .... > *(EXCLUDE_FILE (*liblibrary.a:) .text .text.* .gnu.linkonce.t.*) > .... > } > > ..cs3.extnor : ALIGN (8) > { > ... > *liblibrary.a:(.text .text.* .gnu.linkonce.t.*) > ... > . = ALIGN (8); > } >extnor > > > > It works as expected (code from the library is placed from 0x80000000) > until I compile the library with -ffunction-sections. Thereafter the linker > ignores input section .cs3.extnor and places everything into .text. > > Is it a bug or I have misunderstood documentation? > > Best Regards, > Martin Velek > > > P.S. > I have tried the latest Codebench (trial) for reproducing the issue. There > are two projects, library - static library, testFS - main program. Both > contain two configuration - DebugOK and DebugNOT_OK. You can the check > function placement from Debug[OK|NOT_OK]/testFS.map. If you recreate the > board, you will lost the content. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: