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:
My conclusion is that MX_GPIO_Init(); crashes upon return indicating a severe problem.
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.