From vikasr at renuelectronics.com Fri Jun 1 14:27:19 2012 From: vikasr at renuelectronics.com (Vikas R) Date: Fri, 1 Jun 2012 19:57:19 +0530 Subject: [arm-gnu] Regarding Double Data Type Support on Cortex M4 Message-ID: <0Lufsm-1RsIMl4AO8-0107Gp@mrelay.perfora.net> Hello Sir/Madam, I am using MK60FN1M0VLQ12 (COTREX-M4) processor for my development. I am using float and double data types in my code. When I perform any mathematical operation on these variables , the processor goes to Hard Fault Exception. Later I have enabled the Floating Point Unit (FPU) present in processor. So now, I can perform any mathematical operations on float datatype but still Hard Fault problem occurs with Double data type. I am using GCC 4.5.2 Compiler for my code. I have used following command to compile my main.c file. The option -mfloat-abi=softfp helps me to support float datatype on MK60FN1M0VLQ12 (COTREX-M4) when I kept FPU enabled. arm-none-eabi-gcc -Wall -mfloat-abi=softfp -mcpu=cortex-m4 -mthumb -Qn -Os -mlong-calls -c main.c -o main.o If you know any GCC compiler commands to solve the above problem, please let me know. Awaiting for your reply, Thanks & Regards, Akash -------------- next part -------------- An HTML attachment was scrubbed... URL: From freddie_chopin at op.pl Fri Jun 1 19:02:27 2012 From: freddie_chopin at op.pl (Freddie Chopin) Date: Fri, 01 Jun 2012 21:02:27 +0200 Subject: [arm-gnu] Regarding Double Data Type Support on Cortex M4 In-Reply-To: <0Lufsm-1RsIMl4AO8-0107Gp@mrelay.perfora.net> References: <0Lufsm-1RsIMl4AO8-0107Gp@mrelay.perfora.net> Message-ID: <4FC911C3.8090008@op.pl> Sourcery G++ does not support FPU - try the linaro toolchain, it has necessary floating-point libraries. https://launchpad.net/gcc-arm-embedded It's updated 4 times a year and you don't have to fill a stupid form to download it... 4\/3!! From carlos_odonell at mentor.com Fri Jun 1 19:11:24 2012 From: carlos_odonell at mentor.com (Carlos O'Donell) Date: Fri, 1 Jun 2012 15:11:24 -0400 Subject: [arm-gnu] Regarding Double Data Type Support on Cortex M4 In-Reply-To: <0Lufsm-1RsIMl4AO8-0107Gp@mrelay.perfora.net> References: <0Lufsm-1RsIMl4AO8-0107Gp@mrelay.perfora.net> Message-ID: <4FC913DC.1060703@mentor.com> On 6/1/2012 10:27 AM, Vikas R wrote: > I have used following command to compile my main.c file. The option -mfloat-abi=softfp helps me to support float datatype on MK60FN1M0VLQ12 (COTREX-M4) when I kept FPU enabled. > arm-none-eabi-gcc -Wall -mfloat-abi=softfp -mcpu=cortex-m4 -mthumb -Qn -Os -mlong-calls -c main.c -o main.o > > If you know any GCC compiler commands to solve the above problem, please let me know. Sourcery CodeBench Lite for ARM EABI does support compiling application code for the Cortex-M4F. The FPU on the Cortex-M4F is not a full VFP so you need to pass: `-mfpu=fpv4-sp-d16 -mfloat-abi=softfp` Without specifying -mfpu you likely generate floating point instructions that are unsupported by the M4F's single-precision floating point unit. Does that help? Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos_odonell at mentor.com carlos at codesourcery.com +1 (613) 963 1026 From list-bastian.schick at sciopta.com Fri Jun 1 20:03:45 2012 From: list-bastian.schick at sciopta.com (42Bastian) Date: Fri, 01 Jun 2012 22:03:45 +0200 Subject: [arm-gnu] Regarding Double Data Type Support on Cortex M4 In-Reply-To: <0Lufsm-1RsIMl4AO8-0107Gp@mrelay.perfora.net> References: <0Lufsm-1RsIMl4AO8-0107Gp@mrelay.perfora.net> Message-ID: <4FC92021.1080804@sciopta.com> Hi > Later I have enabled the Floating Point Unit (FPU) present in processor. So > now, I can perform any mathematical operations on float datatype but still > Hard Fault problem occurs with Double data type. If you read the Cortex-M4F manual carefully, you will see it only supports float, not double. Cheers -- 42Bastian + | http://www.sciopta.com | Fastest direct message passing kernel. | IEC61508 certified. + From freddie_chopin at op.pl Fri Jun 1 22:10:31 2012 From: freddie_chopin at op.pl (Freddie Chopin) Date: Sat, 02 Jun 2012 00:10:31 +0200 Subject: [arm-gnu] Regarding Double Data Type Support on Cortex M4 In-Reply-To: <4FC913DC.1060703@mentor.com> References: <0Lufsm-1RsIMl4AO8-0107Gp@mrelay.perfora.net> <4FC913DC.1060703@mentor.com> Message-ID: <4FC93DD7.8020506@op.pl> W dniu 2012-06-01 21:11, Carlos O'Donell pisze: > Sourcery CodeBench Lite for ARM EABI does support compiling application code for the Cortex-M4F. > > The FPU on the Cortex-M4F is not a full VFP so you need to pass: > > `-mfpu=fpv4-sp-d16 -mfloat-abi=softfp` CodeSourcery supports generating code for this chip, but it does not support the FPU... With linaro you can use: -mfloat-abi=hard -mfpu=fpv4-sp-d16 -ffast-math Guess which is faster (; CodeSourcery: c:\Program Files\CodeSourcery\Sourcery_CodeBench_Lite_for_ARM_EABI\bin>arm-none-eabi-gcc -print-multi-lib .; thumb;@mthumb armv6-m;@mthumb at march=armv6-m thumb2;@mthumb at march=armv7 at mfix-cortex-m3-ldrd linaro: c:\Program Files\linaro\4.6 2012q1\bin>arm-none-eabi-gcc -print-multi-lib .; thumb;@mthumb fpu;@mfloat-abi=hard armv6-m;@mthumb at march=armv6s-m armv7-m;@mthumb at march=armv7-m armv7e-m;@mthumb at march=armv7e-m armv7-r/thumb;@mthumb at march=armv7-r armv7-r/thumb/fpu;@mthumb at mfloat-abi=hard at march=armv7-r at mfpu=vfpv3-d16 armv7e-m/fpu;@mthumb at mfloat-abi=hard at march=armv7e-m at mfpu=fpv4-sp-d16 armv7-r/thumb/softfp;@mthumb at mfloat-abi=softfp at march=armv7-r at mfpu=vfpv3-d16 armv7e-m/softfp;@mthumb at mfloat-abi=softfp at march=armv7e-m at mfpu=fpv4-sp-d16 4\/3!! From carlos_odonell at mentor.com Sat Jun 2 02:32:05 2012 From: carlos_odonell at mentor.com (Carlos O'Donell) Date: Fri, 1 Jun 2012 22:32:05 -0400 Subject: [arm-gnu] Regarding Double Data Type Support on Cortex M4 In-Reply-To: <4FC93DD7.8020506@op.pl> References: <0Lufsm-1RsIMl4AO8-0107Gp@mrelay.perfora.net> <4FC913DC.1060703@mentor.com> <4FC93DD7.8020506@op.pl> Message-ID: <4FC97B25.5080207@mentor.com> On 6/1/2012 6:10 PM, Freddie Chopin wrote: > W dniu 2012-06-01 21:11, Carlos O'Donell pisze: >> Sourcery CodeBench Lite for ARM EABI does support compiling application code for the Cortex-M4F. >> >> The FPU on the Cortex-M4F is not a full VFP so you need to pass: >> >> `-mfpu=fpv4-sp-d16 -mfloat-abi=softfp` > > CodeSourcery supports generating code for this chip, but it does not support the FPU... With linaro you can use: > > -mfloat-abi=hard -mfpu=fpv4-sp-d16 -ffast-math > > Guess which is faster (; The best benchmark is your own application. Please don't guess :-) Please also ensure that -ffast-math is exactly what you need since it deviates from IEEE 754. Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos_odonell at mentor.com carlos at codesourcery.com +1 (613) 963 1026 From carlos_odonell at mentor.com Mon Jun 4 15:23:25 2012 From: carlos_odonell at mentor.com (Carlos O'Donell) Date: Mon, 4 Jun 2012 11:23:25 -0400 Subject: [arm-gnu] Regarding Double Data Type Support on Cortex M4 In-Reply-To: <4FCCD2B3.6030002@mentor.com> References: <4FCCD2B3.6030002@mentor.com> Message-ID: <4FCCD2ED.20806@mentor.com> On 6/4/2012 2:22 AM, Vikas R wrote: > Hello Carlos, > Thanks for your prompt reply. > > I made changes suggested by you (i.e. I added `-mfpu=fpv4-sp-d16 > -mfloat-abi=softfp)option in command, but it is still not working. Processor > goes in to hard fault for the "double" data types. > > I have also tried following command for emulated "float" data > type keeping FPU disabled but still not working. > > arm-none-eabi-gcc -Wall -mfpu=fpv4-sp-d16 -mfloat-abi=soft > -mcpu=cortex-m4 -mthumb -Qn -Os -mlong-calls -c main.c -o main.o > > we are using Code Sourcery G++ Light Version 4.5.2. > > Is it possible to support "float" and "double" data types without > enabling FPU? [including the public list this time around] Yes, that's what -mfloat-abi=soft does. If `-mfloat-abi=soft' doesn't work then something else is wrong with your application. Try using `arm-none-eabi-objdump -ldr ' and review the instructions being used in your final application. When you debug this *exactly* which instruction causes the fault? Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos_odonell at mentor.com carlos at codesourcery.com +1 (613) 963 1026 From vikasr at renuelectronics.com Tue Jun 5 12:30:58 2012 From: vikasr at renuelectronics.com (Vikas R) Date: Tue, 5 Jun 2012 18:00:58 +0530 Subject: [arm-gnu] Regarding Double Data Type Support on Cortex M4 In-Reply-To: <4FCCD2ED.20806@mentor.com> Message-ID: <0M6kE0-1RoASv34WS-00wrA5@mrelay.perfora.net> Hello Carlos, As per your suggestion we translated c code in to assembly. Here are the findings :-- Our C Code :- void double_test(void) { volatile double AA = 10.2; volatile double BB = 10.2; volatile double CC = 5.1; if(AA == 10.2) { volatile int i; i = 0; } BB = AA; } Equivalent ASM code generated by compiler is ;-- double_test(): d728: b510 push {r4, lr} d72a: a30e add r3, pc, #56 ;(adr r3, d764 ) d72c: e9d3 2300 ldrd r2, r3, [r3] d730: a10e add r1, pc, #56 ;(adr r1, d76c ) d732: e9d1 0100 ldrd r0, r1, [r1] d736: b088 sub sp, #32 d738: e9cd 2304 strd r2, r3, [sp, #16] d73c: e9cd 2302 strd r2, r3, [sp, #8] d740: e9cd 0100 strd r0, r1, [sp] d744: e9dd 0104 ldrd r0, r1, [sp, #16] d748: 4c05 ldr r4, [pc, #20]; (d760 ) d74a: 47a0 blx r4 d74c: b108 cbz r0, d752 d74e: 2300 movs r3, #0 d750: 9307 str r3, [sp, #28] d752: e9dd 2304 ldrd r2, r3, [sp, #16] d756: e9cd 2302 strd r2, r3, [sp, #8] d75a: b008 add sp, #32 d75c: bd10 pop {r4, pc} d75e: bf00 nop d760: 000334b4 .word 0x000334b4 d764: 66666666 .word 0x66666666 d768: 40246666 .word 0x40246666 d76c: 66666666 .word 0x66666666 d770: 40146666 .word 0x40146666 Also corresponding map file is attached with this mail. Our Points :-- 1) When variables AA,BB and CC are not defined as volatile, hard fault does not occure, because compiler is optimizing the code. 2) Above code is generated by keeping FPU is enabled. Thanks and Regards, Vikas Raskar -----Original Message----- From: Carlos O'Donell [mailto:carlos_odonell at mentor.com] Sent: 04/06/2012 8:53 PM To: arm-gnu at codesourcery.com; vikasr at renuelectronics.com; Freddie Chopin Subject: Re: [arm-gnu] Regarding Double Data Type Support on Cortex M4 On 6/4/2012 2:22 AM, Vikas R wrote: > Hello Carlos, > Thanks for your prompt reply. > > I made changes suggested by you (i.e. I added `-mfpu=fpv4-sp-d16 > -mfloat-abi=softfp)option in command, but it is still not working. Processor > goes in to hard fault for the "double" data types. > > I have also tried following command for emulated "float" data > type keeping FPU disabled but still not working. > > arm-none-eabi-gcc -Wall -mfpu=fpv4-sp-d16 -mfloat-abi=soft > -mcpu=cortex-m4 -mthumb -Qn -Os -mlong-calls -c main.c -o main.o > > we are using Code Sourcery G++ Light Version 4.5.2. > > Is it possible to support "float" and "double" data types without > enabling FPU? [including the public list this time around] Yes, that's what -mfloat-abi=soft does. If `-mfloat-abi=soft' doesn't work then something else is wrong with your application. Try using `arm-none-eabi-objdump -ldr ' and review the instructions being used in your final application. When you debug this *exactly* which instruction causes the fault? Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos_odonell at mentor.com carlos at codesourcery.com +1 (613) 963 1026 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Map.txt URL: From list-bastian.schick at sciopta.com Tue Jun 5 15:40:30 2012 From: list-bastian.schick at sciopta.com (42Bastian) Date: Tue, 05 Jun 2012 17:40:30 +0200 Subject: [arm-gnu] Regarding Double Data Type Support on Cortex M4 In-Reply-To: <0M6kE0-1RoASv34WS-00wrA5@mrelay.perfora.net> References: <0M6kE0-1RoASv34WS-00wrA5@mrelay.perfora.net> Message-ID: <4FCE286E.4040403@sciopta.com> Hi Vikas > d728: b510 push {r4, lr} > d72a: a30e add r3, pc, #56 ;(adr r3, d764 > ) > d72c: e9d3 2300 ldrd r2, r3, [r3] > d730: a10e add r1, pc, #56 ;(adr r1, d76c > ) > d732: e9d1 0100 ldrd r0, r1, [r1] Since no FPU instruction is involved, it is maybe an alignment problem due to the ldrd/strd ? -- 42Bastian + | http://www.sciopta.com | Fastest direct message passing kernel. | IEC61508 certified. + From list-bastian.schick at sciopta.com Tue Jun 5 15:54:49 2012 From: list-bastian.schick at sciopta.com (42Bastian) Date: Tue, 05 Jun 2012 17:54:49 +0200 Subject: [arm-gnu] Regarding Double Data Type Support on Cortex M4 In-Reply-To: <4FC93DD7.8020506@op.pl> References: <0Lufsm-1RsIMl4AO8-0107Gp@mrelay.perfora.net> <4FC913DC.1060703@mentor.com> <4FC93DD7.8020506@op.pl> Message-ID: <4FCE2BC9.7000308@sciopta.com> Hi > CodeSourcery supports generating code for this chip, but it does not > support the FPU... With linaro you can use: Sure CS support float/double: I tried some sample code with these options: -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=hard And it generates fine FPU code for float and uses libraries for double. /* double mult */ ldrd r0, [sp, #24] ldrd r2, [sp, #16] bl __aeabi_dmul strd r0, [sp, #32] /* float mult */ flds s14, [sp, #8] flds s15, [sp, #4] fmuls s15, s14, s15 fsts s15, [sp, #12] -- 42Bastian + | http://www.sciopta.com | Fastest direct message passing kernel. | IEC61508 certified. + From freddie_chopin at op.pl Tue Jun 5 20:15:29 2012 From: freddie_chopin at op.pl (Freddie Chopin) Date: Tue, 05 Jun 2012 22:15:29 +0200 Subject: [arm-gnu] Regarding Double Data Type Support on Cortex M4 In-Reply-To: <4FCE2BC9.7000308@sciopta.com> References: <0Lufsm-1RsIMl4AO8-0107Gp@mrelay.perfora.net> <4FC913DC.1060703@mentor.com> <4FC93DD7.8020506@op.pl> <4FCE2BC9.7000308@sciopta.com> Message-ID: <4FCE68E1.7000903@op.pl> W dniu 2012-06-05 17:54, 42Bastian pisze: >> CodeSourcery supports generating code for this chip, but it does not >> support the FPU... With linaro you can use: > > Sure CS support float/double: Do "arm-none-eabi-gcc -print-multi-lib" and find the libs with hard floating-point support. 4\/3!! From list-bastian.schick at sciopta.com Wed Jun 6 05:21:57 2012 From: list-bastian.schick at sciopta.com (42Bastian) Date: Wed, 06 Jun 2012 07:21:57 +0200 Subject: [arm-gnu] Regarding Double Data Type Support on Cortex M4 In-Reply-To: <4FCE68E1.7000903@op.pl> References: <0Lufsm-1RsIMl4AO8-0107Gp@mrelay.perfora.net> <4FC913DC.1060703@mentor.com> <4FC93DD7.8020506@op.pl> <4FCE2BC9.7000308@sciopta.com> <4FCE68E1.7000903@op.pl> Message-ID: <4FCEE8F5.1060205@sciopta.com> Hi > W dniu 2012-06-05 17:54, 42Bastian pisze: >>> CodeSourcery supports generating code for this chip, but it does not >>> support the FPU... With linaro you can use: >> >> Sure CS support float/double: > > Do "arm-none-eabi-gcc -print-multi-lib" and find the libs with hard > floating-point support. My bad. I missed that my path defaulted to the Linaro gcc. I tested again, and yes, when it comes to libm.a, this is missing from CS gcc. -- 42Bastian + | http://www.sciopta.com | Fastest direct message passing kernel. | IEC61508 certified. + From kalpesh.bafna at einfochips.com Fri Jun 8 07:01:56 2012 From: kalpesh.bafna at einfochips.com (Kalpesh Bafna) Date: Fri, 8 Jun 2012 12:31:56 +0530 Subject: [arm-gnu] Application crashes in vsprintf . build with arm-none-linux-gnueabi References: <008301cd3d6c$9c3a9660$f2026e0a@EIC.COM> Message-ID: <007a01cd4544$9d764940$f2026e0a@EIC.COM> Hi Weso?owski, Thanks for the reply. I am able to solve the crash. I just increased the stack size of that thread (thread created using ptherad_create) while compiling with -O2 option. It was working with -O1 without increasing the stack size. Regards, Kalpesh B. ----- Original Message ----- From: "Krzysztof Weso?owski" To: "Ricardo Anguiano" Cc: "Kalpesh Bafna" ; Sent: Wednesday, May 30, 2012 12:10 AM Subject: Re: [arm-gnu] Application crashes in vsprintf . build with arm-none-linux-gnueabi Reporting bugs without event checking what "crash" means? Usually compiler bug is not the first thing too look at ;) First check if nothing more obvious happens, for example different optimization levels use different amount of stack space. Regards, Krzysztof Weso?owski, tel. +48 721 337 238 On Tue, May 29, 2012 at 8:24 PM, Ricardo Anguiano wrote: > Kalpesh Bafna writes: >> I am using arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2009q1-203) >> 4.3.3 compiler to build the application. > > Sourcerh G++ was rebranded to Sourcery CodeBench. The most recent > Sourcery CodeBench Lite ARM GNU/Linux release (2011.09-70) is two years > newer than what you are using. You can register and download the newest > version here: > > http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/ > >> When i build the application with -O2 optimization it crashes in >> vsprintf. But when i build with -O1 it does not crashes. Does >> anybody have idea on this? > > Sourcery CodeBench Lite is unsupported but someone on this list maybe > able to help if you submit a more detailed bug report. You may find > these pages helpful in generating such a report to this list. > > https://sourcery.mentor.com/GNUToolchain/kbentry216 > http://gcc.gnu.org/bugs/ > > Thanks, > -- > Ricardo Anguiano > Mentor Graphics > +1-510-354-6774 > _______________________________________________ > arm-gnu mailing list > arm-gnu at codesourcery.com > http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu ************************************************************************************************************************************************************* einfochips Business Disclaimer : This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. ************************************************************************************************************************************************************* From martin.velek at gmail.com Sat Jun 9 09:38:46 2012 From: martin.velek at gmail.com (Martin Velek) Date: Sat, 9 Jun 2012 11:38:46 +0200 Subject: [arm-gnu] a function at a fixed offset Message-ID: Hello, I am sorry if this topic is more or less a general question to gnu. I am using LPC2478 (512 KB internal flash, 64KB SRAM) and I would like to place a flash update function at position _START_OF_ROM + 0x200 -> sector 0 (0x0 - 0x1000) which should not be re-flashed and some app would call this function if a flash update is required. I have defined in a linker script a new section with offset . = 0x200; KEEP(*(.rom.bootloader)) // KEEP prevents from optimisation out and the prototype is: int IAP(...) __attribute__ ((used, section (".rom.bootloader"))); It works like a charm but sometimes I am compiling the bootloader with -0s, sometimes some functions are added etc and I am unable to fill the space with some useful functions. I mean that I do not know how to made the linker to place other functions where possible but the IAP must be at 0x200. e.g. without optimisation 0x0 - 0x1A0 ... init code 0x200 - IAP ...... other functions e.g. with -Os 0x0 - 0x100 ... init code 0x100 - 1A0 .. any possible small function that will fit here 0x200 - IAP ...... other functions Thank you for your help Martin Velek From vikasr at renuelectronics.com Mon Jun 11 12:34:27 2012 From: vikasr at renuelectronics.com (Vikas R) Date: Mon, 11 Jun 2012 18:04:27 +0530 Subject: [arm-gnu] Linking error on arm-none-eabi. Message-ID: <0MOxrj-1SYqla00nv-006b4X@mrelay.perfora.net> Hello Sir/Madam, I have two toolchains arm-none-elf(version 3.4.0) and arm-none-eabi (version 4.2.3). I have ported LWIP(TCP/IP stack on AR7 and ARM9 controller). When I use arm-none-elf toolchain every thing works fine, but when I used arm-none-eabi toolchain I get following linking error :- D:\toolchain_4.2.3\arm-none-eabi\bin\../lib\libc.a(lib_a-sbrkr.o): In function `_sbrk_r':sbrkr.c:(.text+0x18): undefined reference to `_sbrk'. My application is standalone application. I have not used any operating system. There are no malloc or calloc related calls in the firmware. Can you please help me on this? Thanks and Regards, Vikas Raskar -------------- next part -------------- An HTML attachment was scrubbed... URL: From list-bastian.schick at sciopta.com Mon Jun 11 12:42:50 2012 From: list-bastian.schick at sciopta.com (42Bastian) Date: Mon, 11 Jun 2012 14:42:50 +0200 Subject: [arm-gnu] Linking error on arm-none-eabi. In-Reply-To: <0MOxrj-1SYqla00nv-006b4X@mrelay.perfora.net> References: <0MOxrj-1SYqla00nv-006b4X@mrelay.perfora.net> Message-ID: <4FD5E7CA.2070604@sciopta.com> Hi > D:\toolchain_4.2.3\arm-none-eabi\bin\../lib\libc.a(lib_a-sbrkr.o): In > function `_sbrk_r':sbrkr.c:(.text+0x18): undefined reference to `_sbrk'. Try adding a C file with these two functions: #ifdef __GNUC__ void __aeabi_unwind_cpp_pr0() { /* empty */ } void __aeabi_unwind_cpp_pr1() { /* empty */ } #endif -- 42Bastian + | http://www.sciopta.com | Fastest direct message passing kernel. | IEC61508 certified. + From carlos_odonell at mentor.com Mon Jun 11 12:55:42 2012 From: carlos_odonell at mentor.com (Carlos O'Donell) Date: Mon, 11 Jun 2012 08:55:42 -0400 Subject: [arm-gnu] Linking error on arm-none-eabi. In-Reply-To: <4FD5E7CA.2070604@sciopta.com> References: <0MOxrj-1SYqla00nv-006b4X@mrelay.perfora.net> <4FD5E7CA.2070604@sciopta.com> Message-ID: <4FD5EACE.7090503@mentor.com> On 6/11/2012 8:42 AM, 42Bastian wrote: > Hi > >> D:\toolchain_4.2.3\arm-none-eabi\bin\../lib\libc.a(lib_a-sbrkr.o): In >> function `_sbrk_r':sbrkr.c:(.text+0x18): undefined reference to `_sbrk'. > > Try adding a C file with these two functions: > > #ifdef __GNUC__ > void __aeabi_unwind_cpp_pr0() > { > /* empty */ > } > void __aeabi_unwind_cpp_pr1() > { > /* empty */ > } > #endif > Or try adding an _sbrk implementation. Although you may have no malloc (or related functions) calls, you could still have an _sbrk call used by the runtime to allocate heap. Generate a link map with -Wl,-Map,linkmap.txt and use the dependency information to determine which object file required _sbrk. This will help you track down what required _sbrk and change it to use a static buffer (or work around the issue in the runtime). Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos_odonell at mentor.com carlos at codesourcery.com +1 (613) 963 1026 From carlos_odonell at mentor.com Mon Jun 11 13:15:38 2012 From: carlos_odonell at mentor.com (Carlos O'Donell) Date: Mon, 11 Jun 2012 09:15:38 -0400 Subject: [arm-gnu] a function at a fixed offset In-Reply-To: References: Message-ID: <4FD5EF7A.5000504@mentor.com> On 6/9/2012 5:38 AM, Martin Velek wrote: > e.g. without optimisation > 0x0 - 0x1A0 ... init code > 0x200 - IAP > ...... other functions > > e.g. with -Os > 0x0 - 0x100 ... init code > 0x100 - 1A0 .. any possible small function that will fit here > 0x200 - IAP > ...... other functions You can definitely do the following: * At -Os __OPTIMIZE_SIZE__ is defined. * Define a section in your linker script and place it in the gap. * When the -Os macro is not defined leave the functions as they are. * When the -Os macro is defined add the section attribute to the functions which places them in the section that resides in teh gap. You might be able to do the following: * At -Os define some symbol. * Define a section in your linker script and fill it with some functions you know fit in the gap. * if DEFINED(symbol) then place the section in the gap. * if !DEFINED(symbol) then leave the section somewhere else. These are just suggestions and I've not tried them. The easy solution is to have two linker scripts. Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos_odonell at mentor.com carlos at codesourcery.com +1 (613) 963 1026 From vaclavpe at seznam.cz Mon Jun 11 14:01:16 2012 From: vaclavpe at seznam.cz (=?us-ascii?Q?Vaclav=20Peroutka?=) Date: Mon, 11 Jun 2012 16:01:16 +0200 (CEST) Subject: [arm-gnu] difference between values from readelf and GDB Message-ID: <316371.10399.21294-2728-541901953-1339423276@seznam.cz> Hello, I have simple linker script for Cortex M3 below. If I use arm-none-eabi-readelf, I can get correct values for _etext, _data, _edata. But if I run arm-none-eabi-gdb with this ELF, I see all values wrong. What is wrong here ? Thank you in advance, Vaclav ENTRY(_start) MEMORY { FLASH (rx) : org = 0x70000000, len = 0x4000000 RAM (rwx) : org = 0x08000000, len = 0x40000 SDRAM (rwx) : org = 0x74000000, len = 0x4000000 } SECTIONS { .text : { *(.vectors*) *(.text*) *(.rodata*); . = ALIGN(4); _etext = .; } > FLASH .data : { _data = .; *(.data*); _edata = .; } > RAM AT > FLASH .bss : { _bss = .; *(.bss*) *(COMMON); _ebss = .; } > RAM .heap : { . = ALIGN(32); __start_heap__ = . ; *(.heap) . = ALIGN(32); __end_heap__ = . ; } >RAM end = .; /DISCARD/ : { *(.eh_frame*); } } PROVIDE(_stack = 0x08010000); From carlos_odonell at mentor.com Mon Jun 11 14:45:05 2012 From: carlos_odonell at mentor.com (Carlos O'Donell) Date: Mon, 11 Jun 2012 10:45:05 -0400 Subject: [arm-gnu] difference between values from readelf and GDB In-Reply-To: <316371.10399.21294-2728-541901953-1339423276@seznam.cz> References: <316371.10399.21294-2728-541901953-1339423276@seznam.cz> Message-ID: <4FD60471.9030307@mentor.com> On 6/11/2012 10:01 AM, Vaclav Peroutka wrote: > Hello, > I have simple linker script for Cortex M3 below. If I use arm-none-eabi-readelf, I can get correct values for _etext, _data, _edata. But if I run arm-none-eabi-gdb with this ELF, I see all values wrong. What is wrong here ? Please provide example gdb usage. Please explain your expected versus observed behaviour. Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos_odonell at mentor.com carlos at codesourcery.com +1 (613) 963 1026 From prashanth_r at hcl.com Mon Jun 11 15:03:31 2012 From: prashanth_r at hcl.com (Prashanth Ravindran) Date: Mon, 11 Jun 2012 20:33:31 +0530 Subject: [arm-gnu] Linking errors for STM32F4-Discovery using Codebench Lite Message-ID: Dear All, My code compiles fine with sourcery_codebench_lite_for_arm_eabi but at the linking stage the following errors are thrown. Am I missing some .o's in my projet. I am using the code sourcery version that uses gcc 4.6.1. The code is in C++. Can you please tell me if I am missing anything. The board that I am targeting is a STM32F4-Discovery board. Apologies if this is a very basic question. I am just moving into the embedded world from the application world. c:/program files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/bin/ld.exe: warning: cannot find entry symbol _start; defaulting to 00008018 c:/program files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-abort.o): In function `abort': abort.c:(.text+0x10): undefined reference to `_exit' c:/program files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-fstatr.o): In function `_fstat_r': fstatr.c:(.text+0x1c): undefined reference to `_fstat' c:/program files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-openr.o): In function `_open_r': openr.c:(.text+0x20): undefined reference to `_open' c:/program files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-sbrkr.o): In function `_sbrk_r': sbrkr.c:(.text+0x18): undefined reference to `_sbrk' c:/program files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-signalr.o): In function `_kill_r': signalr.c:(.text+0x1c): undefined reference to `_kill' c:/program files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-signalr.o): In function `_getpid_r': signalr.c:(.text+0x44): undefined reference to `_getpid' c:/program files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-writer.o): In function `_write_r': writer.c:(.text+0x20): undefined reference to `_write' c:/program files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-closer.o): In function `_close_r': closer.c:(.text+0x18): undefined reference to `_close' c:/program files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-isattyr.o): In function `_isatty_r': isattyr.c:(.text+0x18): undefined reference to `_isatty' c:/program files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-lseekr.o): In function `_lseek_r': lseekr.c:(.text+0x20): undefined reference to `_lseek' c:/program files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-readr.o): In function `_read_r': readr.c:(.text+0x20): undefined reference to `_read' collect2: ld returned 1 exit status make: *** [EIGEN_TEST] Error 1 Thanks, Prashanth ::DISCLAIMER:: ---------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ---------------------------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlos_odonell at mentor.com Mon Jun 11 17:59:22 2012 From: carlos_odonell at mentor.com (Carlos O'Donell) Date: Mon, 11 Jun 2012 13:59:22 -0400 Subject: [arm-gnu] Linking errors for STM32F4-Discovery using Codebench Lite In-Reply-To: References: Message-ID: <4FD631FA.50907@mentor.com> On 6/11/2012 11:03 AM, Prashanth Ravindran wrote: > My code compiles fine with sourcery_codebench_lite_for_arm_eabi but > at the linking stage the following errors are thrown. Am I missing > some .o?s in my projet. I am using the code sourcery version that > uses gcc 4.6.1. The code is in C++. Can you please tell me if I am > missing anything. The board that I am targeting is a > STM32F4-Discovery board. > > > > Apologies if this is a very basic question. I am just moving into the > embedded world from the application world. Welcome! There is a lot to learn. Good luck! > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/bin/ld.exe: > warning: cannot find entry symbol _start; defaulting to 00008018 You are compiling without a linker script or your linker script is broken. You must define a _start symbol, normally in bare-metal this is the same as your reset function. > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-abort.o): > In function `abort': > > abort.c:(.text+0x10): undefined reference to `_exit' You are missing implementations of all your low-level IO routines. You generally need to provide these yourself or your RTOS provides them and you wire them up. Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos_odonell at mentor.com carlos at codesourcery.com +1 (613) 963 1026 From martin.velek at gmail.com Tue Jun 12 08:19:17 2012 From: martin.velek at gmail.com (Martin Velek) Date: Tue, 12 Jun 2012 10:19:17 +0200 Subject: [arm-gnu] Linking errors for STM32F4-Discovery using Codebench Lite In-Reply-To: References: Message-ID: Hello, check this tutorial www.state-machine.com/arm/Building_bare-metal_ARM_with_GNU.pdf . A lot of useful information inside. Martin On Mon, Jun 11, 2012 at 5:03 PM, Prashanth Ravindran wrote: > Dear All, > > > > My code compiles fine with sourcery_codebench_lite_for_arm_eabi but at the > linking stage the following errors are thrown. Am I missing some .o?s in my > projet. I am using the code sourcery version that uses gcc 4.6.1. The code > is in C++. Can you please tell me if I am missing anything. The board that I > am targeting is a STM32F4-Discovery board. > > > > Apologies if this is a very basic question. I am just moving into the > embedded world from the application world. > > > > > > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/bin/ld.exe: > warning: cannot find entry symbol _start; defaulting to 00008018 > > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-abort.o): > In function `abort': > > abort.c:(.text+0x10): undefined reference to `_exit' > > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-fstatr.o): > In function `_fstat_r': > > fstatr.c:(.text+0x1c): undefined reference to `_fstat' > > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-openr.o): > In function `_open_r': > > openr.c:(.text+0x20): undefined reference to `_open' > > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-sbrkr.o): > In function `_sbrk_r': > > sbrkr.c:(.text+0x18): undefined reference to `_sbrk' > > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-signalr.o): > In function `_kill_r': > > signalr.c:(.text+0x1c): undefined reference to `_kill' > > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-signalr.o): > In function `_getpid_r': > > signalr.c:(.text+0x44): undefined reference to `_getpid' > > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-writer.o): > In function `_write_r': > > writer.c:(.text+0x20): undefined reference to `_write' > > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-closer.o): > In function `_close_r': > > closer.c:(.text+0x18): undefined reference to `_close' > > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-isattyr.o): > In function `_isatty_r': > > isattyr.c:(.text+0x18): undefined reference to `_isatty' > > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-lseekr.o): > In function `_lseek_r': > > lseekr.c:(.text+0x20): undefined reference to `_lseek' > > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-readr.o): > In function `_read_r': > > readr.c:(.text+0x20): undefined reference to `_read' > > collect2: ld returned 1 exit status > > make: *** [EIGEN_TEST] Error 1 > > > > Thanks, > > Prashanth > > > > ::DISCLAIMER:: > ---------------------------------------------------------------------------------------------------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. > E-mail transmission is not guaranteed to be secure or error-free as > information could be intercepted, corrupted, > lost, destroyed, arrive late or incomplete, or may contain viruses in > transmission. The e mail and its contents > (with or without referred errors) shall therefore not attach any liability > on the originator or HCL or its affiliates. > Views or opinions, if any, presented in this email are solely those of the > author and may not necessarily reflect the > views or opinions of HCL or its affiliates. Any form of reproduction, > dissemination, copying, disclosure, modification, > distribution and / or publication of this message without the prior written > consent of authorized representative of > HCL is strictly prohibited. If you have received this email in error please > delete it and notify the sender immediately. > Before opening any email and/or attachments, please check them for viruses > and other defects. > > ---------------------------------------------------------------------------------------------------------------------------------------------------- > > > _______________________________________________ > arm-gnu mailing list > arm-gnu at codesourcery.com > http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu > From prashanth_r at hcl.com Tue Jun 12 09:00:13 2012 From: prashanth_r at hcl.com (Prashanth Ravindran) Date: Tue, 12 Jun 2012 14:30:13 +0530 Subject: [arm-gnu] Linking errors for STM32F4-Discovery using Codebench Lite In-Reply-To: References: Message-ID: Dear All, Thanks for all the pointers. Thanks, Prashanth -----Original Message----- From: arm-gnu-bounces at codesourcery.com [mailto:arm-gnu-bounces at codesourcery.com] On Behalf Of Martin Velek Sent: Tuesday, June 12, 2012 1:49 PM To: arm-gnu at codesourcery.com Subject: Re: [arm-gnu] Linking errors for STM32F4-Discovery using Codebench Lite Hello, check this tutorial www.state-machine.com/arm/Building_bare-metal_ARM_with_GNU.pdf . A lot of useful information inside. Martin On Mon, Jun 11, 2012 at 5:03 PM, Prashanth Ravindran wrote: > Dear All, > > > > My code compiles fine with sourcery_codebench_lite_for_arm_eabi but at the > linking stage the following errors are thrown. Am I missing some .o's in my > projet. I am using the code sourcery version that uses gcc 4.6.1. The code > is in C++. Can you please tell me if I am missing anything. The board that I > am targeting is a STM32F4-Discovery board. > > > > Apologies if this is a very basic question. I am just moving into the > embedded world from the application world. > > > > > > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/bin/ld.exe: > warning: cannot find entry symbol _start; defaulting to 00008018 > > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-abort.o): > In function `abort': > > abort.c:(.text+0x10): undefined reference to `_exit' > > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-fstatr.o): > In function `_fstat_r': > > fstatr.c:(.text+0x1c): undefined reference to `_fstat' > > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-openr.o): > In function `_open_r': > > openr.c:(.text+0x20): undefined reference to `_open' > > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-sbrkr.o): > In function `_sbrk_r': > > sbrkr.c:(.text+0x18): undefined reference to `_sbrk' > > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-signalr.o): > In function `_kill_r': > > signalr.c:(.text+0x1c): undefined reference to `_kill' > > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-signalr.o): > In function `_getpid_r': > > signalr.c:(.text+0x44): undefined reference to `_getpid' > > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-writer.o): > In function `_write_r': > > writer.c:(.text+0x20): undefined reference to `_write' > > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-closer.o): > In function `_close_r': > > closer.c:(.text+0x18): undefined reference to `_close' > > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-isattyr.o): > In function `_isatty_r': > > isattyr.c:(.text+0x18): undefined reference to `_isatty' > > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-lseekr.o): > In function `_lseek_r': > > lseekr.c:(.text+0x20): undefined reference to `_lseek' > > c:/program > files/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libc.a(lib_a-readr.o): > In function `_read_r': > > readr.c:(.text+0x20): undefined reference to `_read' > > collect2: ld returned 1 exit status > > make: *** [EIGEN_TEST] Error 1 > > > > Thanks, > > Prashanth > > > > ::DISCLAIMER:: > ---------------------------------------------------------------------------------------------------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. > E-mail transmission is not guaranteed to be secure or error-free as > information could be intercepted, corrupted, > lost, destroyed, arrive late or incomplete, or may contain viruses in > transmission. The e mail and its contents > (with or without referred errors) shall therefore not attach any liability > on the originator or HCL or its affiliates. > Views or opinions, if any, presented in this email are solely those of the > author and may not necessarily reflect the > views or opinions of HCL or its affiliates. Any form of reproduction, > dissemination, copying, disclosure, modification, > distribution and / or publication of this message without the prior written > consent of authorized representative of > HCL is strictly prohibited. If you have received this email in error please > delete it and notify the sender immediately. > Before opening any email and/or attachments, please check them for viruses > and other defects. > > ---------------------------------------------------------------------------------------------------------------------------------------------------- > > > _______________________________________________ > arm-gnu mailing list > arm-gnu at codesourcery.com > http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu > _______________________________________________ arm-gnu mailing list arm-gnu at codesourcery.com http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu From mmulrooney at teledyne.com Thu Jun 21 13:06:40 2012 From: mmulrooney at teledyne.com (Mark Mulrooney) Date: Thu, 21 Jun 2012 06:06:40 -0700 Subject: [arm-gnu] Cortex-M3 and Floating Point Problems Message-ID: Hi Were using the arm-none-eabi to compile for an STM32F103ZG and we seem to be having trouble with floating point operations. The code compiles fine and when I look at the list file I see the calls to the float library functions. We are compiling with the following options -mthumb -mcpu=cortex-m3 -msoft-float. The problem is no floating point operations seem to work on the system. As a simple test I tried the following: float test1 = 10.1234; float test2 = .5678 float answer = test1 * test2 printf("Answer: %f\r\n", answer); It printed out Answer: 0.000000. I was wondering if it may be pulling in arm libraries instead of thumb or something like that. Any help would be greatly appreciated. Thanks, Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlos_odonell at mentor.com Thu Jun 21 17:21:32 2012 From: carlos_odonell at mentor.com (Carlos O'Donell) Date: Thu, 21 Jun 2012 13:21:32 -0400 Subject: [arm-gnu] Cortex-M3 and Floating Point Problems In-Reply-To: References: Message-ID: <4FE3581C.6050703@mentor.com> On 6/21/2012 9:06 AM, Mark Mulrooney wrote: > Were using the arm-none-eabi to compile for an STM32F103ZG and we > seem to be having trouble with floating point operations. The code > compiles fine and when I look at the list file I see the calls to the > float library functions. We are compiling with the following options > ?mthumb ?mcpu=cortex-m3 ?msoft-float. > > The problem is no floating point operations seem to work on the > system. As a simple test I tried the following: > > float test1 = 10.1234; > > float test2 = .5678 > > float answer = test1 * test2 > > printf(?Answer: %f\r\n?, answer); > > > > It printed out Answer: 0.000000. > > > > I was wondering if it may be pulling in arm libraries instead of > thumb or something like that. Any help would be greatly appreciated. If I had to guess... You are using an alternate printf implementation that has buggy %f support? What does the *debugger* actually say is the value of answer? Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos_odonell at mentor.com carlos at codesourcery.com +1 (613) 963 1026 From mmulrooney at teledyne.com Thu Jun 21 18:48:51 2012 From: mmulrooney at teledyne.com (Mark Mulrooney) Date: Thu, 21 Jun 2012 11:48:51 -0700 Subject: [arm-gnu] Cortex-M3 and Floating Point Problems In-Reply-To: <4FE3581C.6050703@mentor.com> References: <4FE3581C.6050703@mentor.com> Message-ID: It appears you are correct, good catch! Now my next question would be why. I'm using the standard libraries provided by CodeSourcery. I did notice while stepping through the code that the last assembly instruction before branching to printf is a ldrd call and I also noticed there is a compiler option for -mfix-cortex-m3-ldrd. I added that in but it still doesn't seem to work correctly. Thanks, Mark -----Original Message----- From: Carlos O'Donell [mailto:carlos_odonell at mentor.com] Sent: Thursday, June 21, 2012 13:22 To: Mark Mulrooney Cc: arm-gnu at codesourcery.com Subject: Re: [arm-gnu] Cortex-M3 and Floating Point Problems On 6/21/2012 9:06 AM, Mark Mulrooney wrote: > Were using the arm-none-eabi to compile for an STM32F103ZG and we seem > to be having trouble with floating point operations. The code compiles > fine and when I look at the list file I see the calls to the float > library functions. We are compiling with the following options -mthumb > -mcpu=cortex-m3 -msoft-float. > > The problem is no floating point operations seem to work on the > system. As a simple test I tried the following: > > float test1 = 10.1234; > > float test2 = .5678 > > float answer = test1 * test2 > > printf("Answer: %f\r\n", answer); > > > > It printed out Answer: 0.000000. > > > > I was wondering if it may be pulling in arm libraries instead of thumb > or something like that. Any help would be greatly appreciated. If I had to guess... You are using an alternate printf implementation that has buggy %f support? What does the *debugger* actually say is the value of answer? Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos_odonell at mentor.com carlos at codesourcery.com +1 (613) 963 1026 From carlos_odonell at mentor.com Thu Jun 21 19:18:24 2012 From: carlos_odonell at mentor.com (Carlos O'Donell) Date: Thu, 21 Jun 2012 15:18:24 -0400 Subject: [arm-gnu] Cortex-M3 and Floating Point Problems In-Reply-To: References: <4FE3581C.6050703@mentor.com> Message-ID: <4FE37380.3030806@mentor.com> On 6/21/2012 2:48 PM, Mark Mulrooney wrote: > It appears you are correct, good catch! Now my next question would be > why. I'm using the standard libraries provided by CodeSourcery. I did > notice while stepping through the code that the last assembly > instruction before branching to printf is a ldrd call and I also > noticed there is a compiler option for -mfix-cortex-m3-ldrd. I added > that in but it still doesn't seem to work correctly. The `-mfix-cortex-m3-ldrd' is automatically enabled when you specify -mcpu=cortex-m3. You haven't provided a test case or linker map file so all we can do is guess. The Sourcery CodeBench bare-metal C library is ISO C compabitle and therefore provides %f support. Care to add `-Wl,-Map,linkermap.txt` to your final link with gcc and look to see there where printf is coming from? Some other options might be: * You used macro tricks to call iprintf instead of printf to make the executable smaller, but forgot iprintf doesn't support %f? * You aren't using the CodeBench printf, and the alternate printf doesn't support %f? * And lastly... the CodeBench printf has a bug. Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos_odonell at mentor.com carlos at codesourcery.com +1 (613) 963 1026 From krzysztof.wesolowski at rainlabs.pl Thu Jun 21 19:32:41 2012 From: krzysztof.wesolowski at rainlabs.pl (=?ISO-8859-2?Q?Krzysztof_Weso=B3owski?=) Date: Thu, 21 Jun 2012 21:32:41 +0200 Subject: [arm-gnu] Cortex-M3 and Floating Point Problems In-Reply-To: <4FE37380.3030806@mentor.com> References: <4FE3581C.6050703@mentor.com> <4FE37380.3030806@mentor.com> Message-ID: > * And lastly... the CodeBench printf has a bug. > One more possible reason is that AFAIR printf with %f uses malloc for memory allocation, and often malloc or underlying sbrk are not prepared (by user) to work on MCUs (in many example projects I have seen there was no such support and compiler reports undefined reference, and then, sometimes not functional code is added just to stop errors ;)). Regards, Krzysztof Weso?owski, From mmulrooney at teledyne.com Thu Jun 21 19:38:18 2012 From: mmulrooney at teledyne.com (Mark Mulrooney) Date: Thu, 21 Jun 2012 12:38:18 -0700 Subject: [arm-gnu] Cortex-M3 and Floating Point Problems In-Reply-To: <4FE37380.3030806@mentor.com> References: <4FE3581C.6050703@mentor.com> <4FE37380.3030806@mentor.com> Message-ID: The printf being pulled in is from the thumb2/libc.a file according to the map file; I've attached the map file. We are not using any macros iprintf as far as I know. I'm not sure I understand what you mean by the CodeBench printf vs the alternative printf. We do not use CodeBench at all, we are using makefiles and the compiler. Thanks, Mark -----Original Message----- From: Carlos O'Donell [mailto:carlos_odonell at mentor.com] Sent: Thursday, June 21, 2012 15:18 To: Mark Mulrooney Cc: arm-gnu at codesourcery.com Subject: Re: [arm-gnu] Cortex-M3 and Floating Point Problems On 6/21/2012 2:48 PM, Mark Mulrooney wrote: > It appears you are correct, good catch! Now my next question would be > why. I'm using the standard libraries provided by CodeSourcery. I did > notice while stepping through the code that the last assembly > instruction before branching to printf is a ldrd call and I also > noticed there is a compiler option for -mfix-cortex-m3-ldrd. I added > that in but it still doesn't seem to work correctly. The `-mfix-cortex-m3-ldrd' is automatically enabled when you specify -mcpu=cortex-m3. You haven't provided a test case or linker map file so all we can do is guess. The Sourcery CodeBench bare-metal C library is ISO C compabitle and therefore provides %f support. Care to add `-Wl,-Map,linkermap.txt` to your final link with gcc and look to see there where printf is coming from? Some other options might be: * You used macro tricks to call iprintf instead of printf to make the executable smaller, but forgot iprintf doesn't support %f? * You aren't using the CodeBench printf, and the alternate printf doesn't support %f? * And lastly... the CodeBench printf has a bug. Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos_odonell at mentor.com carlos at codesourcery.com +1 (613) 963 1026 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: apf11.map URL: From mmulrooney at teledyne.com Thu Jun 21 19:40:09 2012 From: mmulrooney at teledyne.com (Mark Mulrooney) Date: Thu, 21 Jun 2012 12:40:09 -0700 Subject: [arm-gnu] Cortex-M3 and Floating Point Problems In-Reply-To: References: <4FE3581C.6050703@mentor.com> <4FE37380.3030806@mentor.com>, Message-ID: I have manually implemented the underlying _sbrk function. I've pasted the code below just in case I've made some silly mistake but as far as I know it seems to be working. /** ******************************************************************************************************** * @fn _sbrk(int incr) * @brief Increase program data space. Malloc and similar functions depend on this * @param incr: The amount of space to grab * @return Returns the address to the allocated space on success * @return Returns -1 on failure ******************************************************************************************************** */ caddr_t _sbrk(int incr) { unsigned char *prev_heap; static unsigned char *heap = NULL; /* If the heap var is NULL, set it to the start of the heap */ if(heap == NULL) { heap = (unsigned char *)&_heap_start; } /* Save the current heap location */ prev_heap = heap; /* Make sure the stack and the heap don't collide */ if((heap + incr) > (unsigned char*) &_sstack) { return (caddr_t) -1; } /* Increase by the increment amount and return the address */ heap += incr; return (caddr_t) prev_heap; } ________________________________________ From: Krzysztof Weso?owski [krzysztof.wesolowski at rainlabs.pl] Sent: Thursday, June 21, 2012 3:32 PM To: Carlos O'Donell Cc: Mark Mulrooney; arm-gnu at codesourcery.com Subject: Re: [arm-gnu] Cortex-M3 and Floating Point Problems > * And lastly... the CodeBench printf has a bug. > One more possible reason is that AFAIR printf with %f uses malloc for memory allocation, and often malloc or underlying sbrk are not prepared (by user) to work on MCUs (in many example projects I have seen there was no such support and compiler reports undefined reference, and then, sometimes not functional code is added just to stop errors ;)). Regards, Krzysztof Weso?owski, From ricardo_anguiano at mentor.com Thu Jun 21 20:15:15 2012 From: ricardo_anguiano at mentor.com (Ricardo Anguiano) Date: Thu, 21 Jun 2012 13:15:15 -0700 Subject: [arm-gnu] Cortex-M3 and Floating Point Problems In-Reply-To: References: <4FE3581C.6050703@mentor.com> <4FE37380.3030806@mentor.com> Message-ID: <4FE380D3.5090707@mentor.com> On 06/21/2012 12:38 PM, Mark Mulrooney wrote: > We do not use CodeBench at all, we are using makefiles and the compiler. If you are using the compiler from a CodeBench Lite edition installation, you are likely also using our libraries. I would like to clarify: What is CodeBench? Sourcery CodeBench Lite edition includes the entire toolchain (compiler, debugger, runtime libraries, etc) and is command line only. Personal, Standard and Professional editions include Eclipse integration (and much more) and may be used from either the command line or with the IDE. You can see the differences between editions here: http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/ Thanks, -- Ricardo Anguiano Mentor Graphics +1-510-354-6774 From paul at codesourcery.com Thu Jun 21 20:41:52 2012 From: paul at codesourcery.com (Paul Brook) Date: Thu, 21 Jun 2012 21:41:52 +0100 Subject: [arm-gnu] Cortex-M3 and Floating Point Problems In-Reply-To: References: <4FE3581C.6050703@mentor.com> Message-ID: <201206212141.53458.paul@codesourcery.com> > > printf("Answer: %f\r\n", answer); > > It printed out Answer: 0.000000. > It appears you are correct, good catch! Now my next question would be why. This usually means your startup code has left the stack incorrectly aligned (typically off by 4). The stack pointer must be aligned to an 8 byte boundary. Paul From mmulrooney at teledyne.com Thu Jun 21 21:02:11 2012 From: mmulrooney at teledyne.com (Mark Mulrooney) Date: Thu, 21 Jun 2012 14:02:11 -0700 Subject: [arm-gnu] Cortex-M3 and Floating Point Problems In-Reply-To: <201206212141.53458.paul@codesourcery.com> References: <4FE3581C.6050703@mentor.com> <201206212141.53458.paul@codesourcery.com> Message-ID: Thanks Paul, that did the trick! Since we're running the Micrium RTOS each task's stack was not aligned to an 8 byte boundry. -----Original Message----- From: Paul Brook [mailto:paul at codesourcery.com] Sent: Thursday, June 21, 2012 16:42 To: arm-gnu at codesourcery.com Cc: Mark Mulrooney; Carlos O'Donell Subject: Re: [arm-gnu] Cortex-M3 and Floating Point Problems > > printf("Answer: %f\r\n", answer); > > It printed out Answer: 0.000000. > It appears you are correct, good catch! Now my next question would be why. This usually means your startup code has left the stack incorrectly aligned (typically off by 4). The stack pointer must be aligned to an 8 byte boundary. Paul From carlos_odonell at mentor.com Fri Jun 22 13:29:55 2012 From: carlos_odonell at mentor.com (Carlos O'Donell) Date: Fri, 22 Jun 2012 09:29:55 -0400 Subject: [arm-gnu] Cortex-M3 and Floating Point Problems In-Reply-To: References: <4FE3581C.6050703@mentor.com> <201206212141.53458.paul@codesourcery.com> Message-ID: <4FE47353.8030006@mentor.com> On 6/21/2012 5:02 PM, Mark Mulrooney wrote: > Thanks Paul, that did the trick! Since we're running the Micrium RTOS > each task's stack was not aligned to an 8 byte boundry. Excellent! That's odd that the stack is *not* aligned to an 8-byte boundary as that is a *requirement* under the EABI. Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos_odonell at mentor.com carlos at codesourcery.com +1 (613) 963 1026 From mmulrooney at teledyne.com Fri Jun 22 13:53:03 2012 From: mmulrooney at teledyne.com (Mark Mulrooney) Date: Fri, 22 Jun 2012 06:53:03 -0700 Subject: [arm-gnu] Cortex-M3 and Floating Point Problems In-Reply-To: <4FE47353.8030006@mentor.com> References: <4FE3581C.6050703@mentor.com> <201206212141.53458.paul@codesourcery.com> <4FE47353.8030006@mentor.com> Message-ID: I hate to say this, but I think I may have spoken too soon. Yesterday after Paul's suggestion that it has to be on an 8 byte boundary, I put the following on all the stacks: __attribute__ ((align (8))). I compiled it, ran the system, and it immediately printed out the correct answer. Thinking that solved the problem I moved on to make some changes in another part of the system and now the printf no longer works again. I backed out those changes and the printf still does not work so I don't think it was anything I added. I have seen it before where it works every once in a blue moon and that's why I was convinced it was the 8 byte boundary problem. Carlos: You had mentioned there was a bug in printf with regards to %f, does this sound at all like that bug? Also I was wondering if anyone knows of a good alternative printf/scanf library to use. Thanks, Mark -----Original Message----- From: Carlos O'Donell [mailto:carlos_odonell at mentor.com] Sent: Friday, June 22, 2012 09:30 To: Mark Mulrooney Cc: Paul Brook; arm-gnu at codesourcery.com Subject: Re: [arm-gnu] Cortex-M3 and Floating Point Problems On 6/21/2012 5:02 PM, Mark Mulrooney wrote: > Thanks Paul, that did the trick! Since we're running the Micrium RTOS > each task's stack was not aligned to an 8 byte boundry. Excellent! That's odd that the stack is *not* aligned to an 8-byte boundary as that is a *requirement* under the EABI. Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos_odonell at mentor.com carlos at codesourcery.com +1 (613) 963 1026 From carlos_odonell at mentor.com Fri Jun 22 14:10:13 2012 From: carlos_odonell at mentor.com (Carlos O'Donell) Date: Fri, 22 Jun 2012 10:10:13 -0400 Subject: [arm-gnu] Cortex-M3 and Floating Point Problems In-Reply-To: References: <4FE3581C.6050703@mentor.com> <201206212141.53458.paul@codesourcery.com> <4FE47353.8030006@mentor.com> Message-ID: <4FE47CC5.4000408@mentor.com> On 6/22/2012 9:53 AM, Mark Mulrooney wrote: > I hate to say this, but I think I may have spoken too soon. Yesterday > after Paul's suggestion that it has to be on an 8 byte boundary, I > put the following on all the stacks: __attribute__ ((align (8))). I > compiled it, ran the system, and it immediately printed out the > correct answer. Thinking that solved the problem I moved on to make > some changes in another part of the system and now the printf no > longer works again. I backed out those changes and the printf still > does not work so I don't think it was anything I added. I have seen > it before where it works every once in a blue moon and that's why I > was convinced it was the 8 byte boundary problem. So this sounds like something is breaking the stack boundary requirements. Can you look at the stack alignment at entry to several functions? > Carlos: You had mentioned there was a bug in printf with regards to > %f, does this sound at all like that bug? No, I was just generically stating that there could be an unfound bug, but I don't know of any. > Also I was wondering if anyone knows of a good alternative > printf/scanf library to use. What about the one in the STM32 Firmware Library? Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos_odonell at mentor.com carlos at codesourcery.com +1 (613) 963 1026 From mmulrooney at teledyne.com Mon Jun 25 19:58:47 2012 From: mmulrooney at teledyne.com (Mark Mulrooney) Date: Mon, 25 Jun 2012 12:58:47 -0700 Subject: [arm-gnu] Cortex-M3 and Floating Point Problems In-Reply-To: <4FE47CC5.4000408@mentor.com> References: <4FE3581C.6050703@mentor.com> <201206212141.53458.paul@codesourcery.com> <4FE47353.8030006@mentor.com> <4FE47CC5.4000408@mentor.com> Message-ID: So it looks like it was the stack alignment problem. Unfortunately, I just can't read :( I had __attribute__ ((align (8))) and I missed GCC's warning stating it was ignoring the attribute align. It should read __attribute__ ((aligned (8))). Thanks for all your help! Cheers, Mark -----Original Message----- From: Carlos O'Donell [mailto:carlos_odonell at mentor.com] Sent: Friday, June 22, 2012 10:10 To: Mark Mulrooney Cc: Paul Brook; arm-gnu at codesourcery.com Subject: Re: [arm-gnu] Cortex-M3 and Floating Point Problems On 6/22/2012 9:53 AM, Mark Mulrooney wrote: > I hate to say this, but I think I may have spoken too soon. Yesterday > after Paul's suggestion that it has to be on an 8 byte boundary, I put > the following on all the stacks: __attribute__ ((align (8))). I > compiled it, ran the system, and it immediately printed out the > correct answer. Thinking that solved the problem I moved on to make > some changes in another part of the system and now the printf no > longer works again. I backed out those changes and the printf still > does not work so I don't think it was anything I added. I have seen it > before where it works every once in a blue moon and that's why I was > convinced it was the 8 byte boundary problem. So this sounds like something is breaking the stack boundary requirements. Can you look at the stack alignment at entry to several functions? > Carlos: You had mentioned there was a bug in printf with regards to > %f, does this sound at all like that bug? No, I was just generically stating that there could be an unfound bug, but I don't know of any. > Also I was wondering if anyone knows of a good alternative > printf/scanf library to use. What about the one in the STM32 Firmware Library? Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos_odonell at mentor.com carlos at codesourcery.com +1 (613) 963 1026