[arm-gnu] Hard fault caused by blx instruction using printf on Cortex-M3 with CodeSourcery 2008q3-66
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[arm-gnu] Hard fault caused by blx instruction using printf on Cortex-M3 with CodeSourcery 2008q3-66
- To: arm-gnu@xxxxxxxxxxxxxxxx
- Subject: [arm-gnu] Hard fault caused by blx instruction using printf on Cortex-M3 with CodeSourcery 2008q3-66
- From: Peter Laurich <Peter.Laurich@xxxxxxxxxxx>
- Date: Thu, 21 May 2009 12:30:45 -0400
Hi,
I am using the CodeSourcery G++ Lite toolchain
arm-2008q3-66-arm-none-eabi to
generate code to run on the ST Micro STM3210E-EVAL board. My tool chain
is
running on Linux but a colleague is having the same problem running on
Windows.
The problem is that the execution of the following C code results in a
hard fault:
int i = 10;
printf("i = %10d\r\n", i);
In working through the problem, it appears that the cause of the hard
fault
is the illegal instruction (on the Cortex-M3):
0x00002f82 <_vfprintf_r+3090>: blx 0x7834 <__aeabi_uldivmod>
The call to the gcclib aeabi_uldivmod from the libc vfprintf includes
uses blx
with an even address and this causes the hard fault.
My simplified gcc compile invocation is:
Building file: ../Examples/USART/Printf/main.c
Invoking: GCC C Compiler
arm-none-eabi-gcc -O0 -g -ggdb -Wall -Werror -c -fmessage-length=0
-mthumb
-march=armv7-m -mfix-cortex-m3-ldrd
My simplified linker invokation is:
Building target: STM32_StdPeriph.axf
Invoking: GCC C Linker
arm-none-eabi-ld -nostartfiles -nodefaultlibs -nostdlib -static
-L/home/peterL/platforms/ARM/arm-none-eabi/tools/arm-none-eabi/lib/thumb
-L/home/peterL/platforms/ARM/arm-none-eabi/tools/lib/gcc/arm-none-eabi/4.3.2/thumb
-Tstm32_512_64_internal.ld --gc-sections -Map=STM32_StdPeriph.map
-o"STM32_StdPeriph.axf"
-lc -lgcc
I have also tried the compiler with -mcpu=cortex-m3 and -march=armv7
rather than
-march=armv7-m with the same results.
I have also tried forcing the linker to use the thumb2 libraries but
that too
fails only with the mode of failure is different (bus fault in malloc
rather
than a hard fault); I'm only addressing the hard fault in this posting.
I have searched extensively (hours and hours) in an attempt to find a
solution
but there is nothing out there that resolves my problem. Can anyone shed
some
light on this problem?
Thank you
Peter