SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world.
And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download two short videos (registration required) highlighting:

System Workbench for STM32

Mbed project debug fails.

I’ve finally find a way to import a Mbed project to SW4STM32 (as it’s almost complicated to add mbed-dev and all options to the compiler and linker) and build it in debug config.

I’ve switch to debug perspective but debuger doesn’t seems to execute main.cpp (as debuger doesn’t stop on breakpoints).

What I’ve done:
Create a new project on SW4STM32 :
New C++ Project -> Executable -> AC6 STM32 MCU Project (named Test3)
Choose both debug and Realease config
Select the right board (in my case a NUCLEO-F303K8)
Select “No Firmware” and NOT tag the “Don’t generate startup files”

Then, first I import my Mbed project (named GamelTrophy, exported from Mbed website for AC6 SW4STM32) in src folder using Import -> General -> Archive File.
But as Mbed website doesn’t allow me to include the mbed-dev lib to this project, it contains the builtin mbed library that I don’t want to use. So I remove:
- Setting and Mbed subfolders
- All compiled library (.lib files)
- Mbed.bld
- All project files (.cproject, .project, etc.)

Then I import the mbed-dev library (exported from Mbed website with the right board configuration) in src/GamelTrophy folder using Import -> General -> Archive File.
I remove all root file except : mbed.h (ie : Mbed_config.h, .cproject, .project, .mbed, makefile.targets, mbed-dev Debug.launch, etc.)
I also remove the setting folder and the Toolchain GCC folder.

I then move mbed_config.h file from the project root to the mbed-dev directory
End of imports

Now I setup the configuration of the project.
In Project properties -> C/C++ General -> Paths ans Symbols, I add (in this order) for all configurations and all languages:
- /Test3/src/GamelTrophy
- /Test3/src/GamelTrophy/mbed-dev/platform
- /Test3/src/GamelTrophy/mbed-dev/hal/storage_abstraction
- /Test3/src/GamelTrophy/mbed-dev/hal
- /Test3/src/GamelTrophy/mbed-dev/targets/TARGET_STM/TARGET_STM32F3/TARGET_STM32F303x8/TARGET_NUCLEO_F303K8
- /Test3/src/GamelTrophy/mbed-dev/targets/TARGET_STM/TARGET_STM32F3/TARGET_STM32F303x8/device
- /Test3/src/GamelTrophy/mbed-dev/targets/TARGET_STM/TARGET_STM32F3/TARGET_STM32F303x8
- /Test3/src/GamelTrophy/mbed-dev/targets/TARGET_STM/TARGET_STM32F3/device
- /Test3/src/GamelTrophy/mbed-dev/targets/TARGET_STM/TARGET_STM32F3
- /Test3/src/GamelTrophy/mbed-dev/targets/TARGET_STM
- /Test3/src/GamelTrophy/mbed-dev/cmsis/TARGET_CORTEX_M
- /Test3/src/GamelTrophy/mbed-dev/cmsis
- /Test3/src/GamelTrophy/mbed-dev/drivers
- /Test3/src/GamelTrophy/mbed-dev

and finally I add my own libs :
- /Test3/src/GamelTrophy/IHM

Then I add symbols for all configurations and all languages:
- STM32
- STM32F3
- STM32F30
- STM32F303K8Tx

And I add those 2 symbols (with their values) :


Now I configure the compiler:
In Project properties -> C/C++ Build -> Settings:
- In section MCU G++ Linker -> Miscellaneous, I add to linker flags: -specs=nosys.specs
- In section MCU GCC Compiler -> Optimization, I choose: Optimize for DEBUG
- In section MCU G++ Compiler -> Optimization, I choose: Optimize for DEBUG

Then I can compile my program (without any error) and program my Nucleo-F303K8 board in debug mode (and switch to debug perspective)

Program is running, but i’m in the infinite loop of defaultHandler (startup_stm32.s) meaning that either I’ve a bad vector table or a weird interrupt or that I’ve missed something...

My first breakpoint is on the first line of main.cpp... Meaning that I never enter the main !

Any help ?

As it’s crashing in the startup code, put a breakpoint in that assembly (startup_stm32.s) on the first instruction after “Reset_Handler:” and try stepping through it.

I’d also look at the *.map file to see what was linked. Equivalent information is available by expanding the *.elf program in the Project Explorere view if the elf Binary Parser is installed and enabled.

The default_handler will catch a lot of interrupts so very hard to determine the cause.