The GCC Ride7 STM32 startup script does not jump into SystemInit function

Question

We are a robotics association from ENSEIRB-MATMECA (Bordeaux, France). We are developping some boards and a template project for STM32 devices.

One of our boards embed a STM32F103C4 microcontroller. We use the startup script from gcc ride7 startup_stm32f10x_ld.s.This startup script work until the line "bl SystemInit" is reached. Then, the system doesn't jump to SystemInit() function as he is expected to do and the bootloader is listening again (reset).

Here is the link instruction:

/home/kevin/ausbee-test/Software/Toolchain/arm-none-eabi/bin/arm-none-eabi-gcc -o /home/kevin/ausbee-test/Software/output/project.elf -mthumb -mcpu=cortex-m3 -Wall -Wextra -mcpu=cortex-m3 -mfix-cortex-m3-ldrd -mthumb-interwork -DSTM32F10X_LD -Wl,--gc-sections -Wl,--Map=test.map  -T/home/kevin/ausbee-test/Software/System-CM3/link.ld /home/kevin/ausbee-test/Software/System-CM3/CMSIS/CM3/DeviceSupport/ST/STM32F10x/startup/gcc_ride7/startup_stm32f10x_ld.o /home/kevin/ausbee-test/Software/System-CM3/CMSIS/CM3/CoreSupport/core_cm3.o /home/kevin/ausbee-test/Software/System-CM3/CMSIS/CM3/DeviceSupport/ST/STM32F10x/system_stm32f10x.o /home/kevin/ausbee-test/Software/Project/src/main.o

The test.map file contain the SystemInit symbol.

We use GCC ARM embedded toolchain (https://launchpad.net/gcc-arm-embedded). Our template project work with other devices such as STM32f105.

Do you have any idea where this bug come from?

Thanking you in advance.

Answer 1

Did you check the value of your stack pointer?

I also had this problem once and it was due to the init script of my JTAG debugger setting the stack pointer to an address which was invalid for the microcontroller used. Especially in your case this seems to be a possible problem since the STM32F103 has less RAM than some STM32F105 microcontrollers, meaning that if your JTAG debugger sets the Stack pointer to for example 0x2000fffc it could perfectly work on the STM32F105 and crash on the STM32F103. You would have the exact same effect if your linker script does not set the stack size correctly (this should be 6 or 10 kbytes on the STM32F103C4).

Normally (running without debugger) the stack pointer value should be the first value of your reset vectors, which is also equal to "_estack" (this value is set in your linker script, check the file link.ld). When the function SystemInit is entered the parameters are pushed on the stack. The push instruction will cause a hard fault if the stack pointer is pointing at some address which can not be dereferenced.

To investigate this possibility with gdb you should use "stepi" instead of step to execute only one assembly instruction at a time, you can also check the stack pointer value with "info register".

Good luck/Bonne chance ;-)

Answer 2

Thank you very much Etienne. The problem was that my linker script was for a specific device but not for Low Density and the author made the _estack static (hard coded value) instead of dynamic: I had to replace:

_estack = 0x20010000;

by

_estack = ORIGIN(RAM) + LENGTH(RAM);

And now it works!

If you are interested in our project: https://github.com/Kev-J/ausbee

It is a bit messy and only for test and learning purpose.

Thank you again/merci encore ;)