0

I've been migrating all my STM32 projects to Codeblocks IDE and GCC compiler (arm-none-eabi). The process is using STM's CubeMX to generate the base code, then merge everything to a proper folder with codeblocks project file, .s, .ld, etc.

Noted that my projects using cortexM0 are building and running fine, however for a cortexM4 project (STM32F401RE), lot of wild things are happening when running the built executable, hence my question here.

My guess is that I'm not calling GCC properly or some misconfiguration somewhere.

As "Defines"

STM32F401xE

As "Compiler Options":

-mcpu=cortex-m0 (note: should be -mcpu=cortex-m4) -ffunction-sections -fdata-sections -fno-common -s

As "Linker Options":

-Wl,--gc-sections -Wl,-Map,default/ggmeg.map -T ./STM32F401RETx_FLASH.ld -Wl,--print-memory-usage,--gc-sections,--relax

Any help appreciated. Thank you,

Please note I don't have live debug as I'm using a old segger Jlink as SWD interface. My first debug step is - after HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); - to set a GPIO to 1 then do a while(1){} so I know my code has executed up to this point.

Now the wild things:

  • Compile with -mcpu=cortex-m4, the code crashes before reaching my point.
  • Compile with -mcpu=cortex-m0 (note: the STM32 i'm using is a M4), works better but...
  • If I setup the GPIO to 1 at the end of -and within- MX_GPIO_Init(); the GPIO is set to 1, great.
  • If I setup the GPIO to 1 after MX_GPIO_Init(); it crashes before reaching my section.

My conclusion is that MX_GPIO_Init(); crashes upon return indicating a severe problem.

Improve this question
9
  • you miss -mthumb
    – 0___________
    Commented May 15 at 17:31
  • As an advice - stick to smcubeide
    – 0___________
    Commented May 15 at 17:34
  • Are you setting a valid initial stack pointer at offset 0x0 in your image?
    – pmacfarlane
    Commented May 16 at 8:04
  • @pmacfarlane Thank you, I have 0x00800120 at 0x0. Does that make sense? I've compared to other builts/projects, that value is vastly different each time.
    – ggadde29
    Commented May 16 at 12:20
  • @0___________ Ok thank you. That's the goal of my migration, getting away from that IDE. The -mthumb, should reduce a bit code size but it should have nothing to do with the crash, right. I get the same behaviour.
    – ggadde29
    Commented May 16 at 12:30

1 Answer 1

Reset to default
1

After trial and errors with GCC flags, the issue was found:

-mcpu=cortex-m4 must also be passed to the linker (both the compilator and the linker).

If compiling CubeMX code for STM32F4 or STM32L4 with the -mcpu=cortex-m0 flag. The CubeMX library fails at main points including failure to initialize the PLL and the program will run at 4MHz (speed of the bootloader). Therefore the systick ran - in our case - 20 times slower giving the false impression the program was crashed (it was not). The reason for this issue is unknown since there are no compilation errors and M4 should be able to execute M0 instructions fine.

This only affects cortex M4, not M0.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.