Anyone have advice for me using CodeSourcery gcc package + FWlib?

[alex8]

Posted on April 03, 2009 at 03:23

Anyone have advice for me using CodeSourcery gcc package + FWlib?

[alex8]

Posted on May 17, 2011 at 13:08

Hi,

I'm using the CodeSourcery packaged command line tools on Linux to

compile and link on a linux host.

arm-none-eabi-gcc (Sourcery G++ Lite 2008q3-66) 4.3.2.

I'm wondering if I've really missed something on the complier flags, or if maybe I should reimplement or copy the FWlib functions as I need them.

After a lot of fussing, it works, but is currently generating huge, slow

code. Pretty close to 20k to initialize a few timers and serial port.

If I tried to do any optimize level over -O0, the ''bin'' file winds up

being huge, (536871104 bytes) filled with 0's between 0023540 or so

and 0x4000000000.

The flags I'm using are:

compiler: -I./ -I./FWLib/inc/ -c -fno-common -O0 -g -mcpu=cortex-m3

-mthumb

linker: -T$(LINKERCMDFILE) -nostartfiles

The bin file is created by arm-none-eabi-objcopy -Obinary.

I tried the -combine -fwhole-program trick mentioned here a few days ago..

this got rid of the unused functions, but it also seemed to omit my

vector table, which I've got defined in main as:

Code:

unsigned int * myvectors[76] //was 4

__attribute__ ((section(''vectors'')))= {

(unsigned int *) 0x20000800, // stack pointer

(unsigned int *) main, // code entry point

(unsigned int *) nmi_handler, // NMI handler

(unsigned int *) hardfault_handler, // hard fault handler

etc. etc..

Also, I can't get the compiler to inline functions, maybe this is due to my being stuck with -O0 optimization?

Thanks,

Alex

[disirio]

Posted on May 17, 2011 at 13:08

Hello, I am using the CodeSourcery command line tools with no problems, both the windows and linux versions.

I have no trouble with inline functions and high optimization levels (-Os, -O2 and -O3).

In the project in my signature there is a STM32 demo that works with the CodeSourcery toolchain. You may look at the makefile, compiler options, linker script and startup files.

The makefile defaults to the YAGARTO toolchain (arm-elf-), you will have to change a line in the makefile to arm-none-eabi-.

About the code size, you can have much faster and smaller executables by using: -mabi=apcs-gnu

This option removes the requirement of an 8-bytes aligned stack and makes the code *much* more efficient, it is specified by default in the makefile.

regards,

Giovanni

---

ChibiOS/RT

http://chibios.sourceforge.net

[domen2]

Posted on May 17, 2011 at 13:08

Maybe these help (-O1 works fine here, -O2 or -Os is problematic enough that i've given up on them).

CORTEX_FLAGS=-mcpu=cortex-m3 -mthumb

CFLAGS=$(CORTEX_FLAGS) -fsigned-char -ffunction-sections -mlittle-endian -Wall -g -O1

LDFLAGS=$(CORTEX_FLAGS) -Wl,-T -Xlinker $(NAME).ld -u _start -Wl,-static -Wl,--gc-sections -nostartfiles -Wl,-Map -Xlinker $(NAME).map -o $(NAME).elf

$(OBJCOPY) $(NAME).elf --target=ihex $(NAME).hex

The 0x40000000 suggests something might be with your linker scripts?

[alex8]

Posted on May 17, 2011 at 13:08

Thanks!!!

Being able to use the -O2 option really helps both size and speed.

I took a look at ChibiOS for an example.. this is really helpful to me especially for the linker script. I wish I'd seen this before trying to hack something together out of an old Olimex example and demo code for IAR.

So now I have a modern microcontroller targetable with gcc from Linux!

Cheers,

Alex

[andreas2]

Posted on May 17, 2011 at 13:08

Sorry, it should be ''SCB->VTOR = (u32)myvectors;''

[andreas2]

Posted on May 17, 2011 at 13:08

Hi Alex,

Yes, -combine -fwhole-program will remove your vector table since it isn't referenced anywhere. Putting ''NVIC->VTOR = myvectors;'' in your main will do the trick, and is a good thing anyway. I normally make the vector table an undefined symbol, just to be sure, by passing -uNVIC_DefaultVectorTable as a linker flag, but that doesn't work for some reason when using -combine. It's also good to have an assertion in the linker script to check for a missing table in case it's lost somehow.

For reference, following is the output of a regular compile and link of a main.c containing only calls to one function in each of the library c-files, causing the entire library to be linked in.

arm-none-eabi-gcc -g3 -Os -mthumb -mcpu=cortex-m3 -fno-builtin -Wall -I../src -I../src/libstm32f10x/include -c -o main.o ../src/main.c

[all library files compiled similarly and archived here]

arm-none-eabi-gcc -nostartfiles -mthumb -mcpu=cortex-m3 -Wl,-L.,-L../src/libstm32f10x/ldscripts -Wl,-Map=main.map,--cref -Wl,-Tstm32f10x_flash.ld,-uNVIC_DefaultVectorTable main.o libstm32f10x.a -lm -o main

arm-none-eabi-size main

text data bss dec hex filename

16148 0 4 16152 3f18 main

Size with -O0: 51660

Size with -O2: 18612

Size with -O3: 22604

Size with -O2 -combine -fwhole-program: 404

Size with -Os -mabi=apcs-gnu: 16508 (larger)

I've had no problems with -O2, which I use generally for production code at work.