Improve the handling of errors so we can find out what caused the error.

Niklas Johansson gave us this hint:

From
http://www.keil.com/forum/14555/

The Cortex-M pushes 8 registers on the stack on Hard Fault exception. Here is a code to read the memory address that caused it:

MRS     R0,PSP                  ; Read PSP
LDR     R1,[R0,#24]             ; Read Saved PC from Stack

See also:

• https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/DispForm.aspx?ID=11388
• http://forums.arm.com/index.php?/topic/13632-invpc-hard-fault-exception-error/
• www.keil.com/appnotes/files/apnt209.pdf

test03 sprintf

• SHA: 55ff50d

There is a problem using sprintf.

Basic use of sprintf like

sprintf(str, "1234") 

turns into memcpy and works.

But when using some more advanced with %d it fails during linking

sprintf(str, "%d", 4321);

We get this link error:

..linking
arm-none-eabi-gcc  -Tsrc/stm32.ld -nostartfiles -mcpu=cortex-m3 -mthumb  -mfix-cortex-m3-ldrd -o main.elf main.o startup_stm32f10x.o test03.o
/usr/local/stm32/lib/gcc/arm-none-eabi/4.4.5/../../../../arm-none-eabi/lib/thumb/libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk'

More data

From

• arm-none-eabi-objdump -S test03.o

    sprintf(str, "1234");
  be:   68bb        ldr r3, [r7, #8]
  c0:   4618        mov r0, r3
  c2:   f240 0100   movw    r1, #0
  c6:   f2c0 0100   movt    r1, #0
  ca:   f04f 0205   mov.w   r2, #5
  ce:   f7ff fffe   bl  0 <memcpy>

    sprintf(str, "%d", 4321);
  fa:   68bb        ldr r3, [r7, #8]
  fc:   4618        mov r0, r3
  fe:   f240 0100   movw    r1, #0
 102:   f2c0 0100   movt    r1, #0
 106:   f241 02e1   movw    r2, #4321   ; 0x10e1
 10a:   f7ff fffe   bl  0 <sprintf>

Thanks to Soeren Apel:

On http://fun-tech.se/stm32/OlimexBlinky/ld_float.php you mention a workaround for ld's inability to link the float library functions. It appears that this is caused by the need for multi-pass symbol resolving. The workaround you mention does work but it's unfortunately something I'd consider a hack. A cleaner approach to solving the issue is to make ld repeatedly resolve the symbols of the object files and the required gcc library:

$(LD) $(LFLAGS) -o main.elf --start-group -lgcc main.o startup_stm32f10x.o --end-group

More or less change

LD      = arm-none-eabi-gcc
$(LD) $(LFLAGS) -o main.elf main.o startup_stm32f10x.o

into

LD      = arm-none-eabi-ld
$(LD) $(LFLAGS) -o main.elf --start-group -lgcc main.o startup_stm32f10x.o --end-group