Loading...
 

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


Project TARGET setting issues

I am experiencing a problem with SW4STM32 pertaining to the Target MCU selection, that you access via:

Project (menu) -> Properties -> C/C++ Build (list) -> Settings (list) -> Target (tab)

On the Target tab page (tab marked with blue-and-white STM butterfly logo), there are dropdown lists for “Series”, “MCU” and (if available) “Board”.

I often find that if I attempt to change the MCU setting, esp. if there is no available “Board” for it, that the setting is NOT applied to the project/configuration. This is true even after explicitly selecting the Apply or OK buttons on the Property dialog.

I realize that one normally selects the target MCU when a project is first created. This works without issue. I am also aware of the potential risks in changing the Target setting on a pre-existing project. However, there are cases where I need to be able to change the target MCU after a project is created. One example of this is a project that shares a common code base targeted to multiple hardware platforms. I am working on several projects that fall into this category. I make use of Eclipse’s multiple “Build Configuration” feature to set target-specific global defines, file paths, compiler, link and other build options - including the target MCU.

All of the various options (at least those that I’ve needed to change on a target/build configuration basis) appear to work correctly; the changes made to them are applied to the currently selected build configuration. However, the settings on the Target tab are not saved. If I change a setting on the Target tab, apply it, then navigate off that tab and come back to it, I find that the setting I just selected has reverted back to its original value.

This issue is not something that is new with the latest version of SW4STM32 (using v13.0 at present) - it is something that has been a problem since I started using SW almost 2 years ago.

France

Hello MSchultz,

My first guess is you should be able to proceed the way you want if updating target MCU you’re setting a board name too (even a dummy one but not empty one ! ). Sounds to me Apply / Ok is only considering target update if some board material (back even dummy one) is specified.

Please have a try and let us know if it works ok for you.

Br,
cartu38

Thank you for looking into this.

I can’t seem to find or remember what one has to do to create a new BOARD definition. I know I did this once before, but I found it by accident.

How do I go about creating a new board definition associated with a given MCU/target? I don’t need the whole process explained step-by-step (I can figure that out myself smile) I just need to know where to look for the “create new board” function.

France

Hello,

As far as I’m aware about the only way Thanks UI to create a new board is to create a new project. New project wizard is only integrated way to get right UI pop-up.

Such said there’s a handmade way to add a new board.
1) Locate your local System Workbench board repository (by default (if windows) = C:\Users\AppData\Roaming\Ac6\SW4STM32\board_def)
2) Add per custom board an .xml file, naming such file in sync. with board name you’re expecting (lower case file name is mandatory)
3) Such .xml (myboard.xml here) file looks like attached file (board id field has to be lower case – board name supports capitals – mcu id has to be lower case) :
4) Once done just restart System Workbench … your added board(s) should be seen as part of current db !


But back to your primary usage sounds to me strict new board creation is not mandatory (but you can ! … up to you). “Strict” stands for adding a board to system workbench db having capability to reuse it from one project to another and/or from one workspace to another. If my understanding is right you’re “only” looking to play with multiple build configurations within a project what’s not requiring such db update. Quick way for you is just to set per build configuration a unique “dummy” board name (typing it within board combo) within build settings target tab (see snapshot attached to such reply).


Back Thanks to share your trials outcomes it will help us !

Br,
cartu38


Thank you cartu, I will give your suggestions a try and let you know how it works out.

The main reason I want to be able to change the target MCU on a per-build-configuration basis is that my project needs to be able to be built to run on several different hardware platforms, all which use different STM32 variants - some of these are M0-core devices, others are M4. (STM32F0xx vs. STM32F3xx). The compiler needs to know what core it needs to build to; this is set with gcc’s -mcpu= command line option. The only way to get the auto-generated compiler invocation to include the right -mcpu= setting is to specify the proper STM32 device in the TARGET setting tab. I suspect that the TARGET setting also affects other aspects of the build process and IDE operation, but it’s the -mcpu compiler option setting that I’m particularly interested in.

The sort of things that are specified by the BOARD xml are not that critical, as they can all be customized when setting up a debug configuration.

My suggestion for the future would be to remove the mandatory board-setting requirement from the TARGET specification, or provide a ‘generic’ or ‘default’ board config for all MCUs, or assume that if the BOARD setting is not specified, that a predefined “default” board config should be used.

France

Hello,

Sounds your suggestion has been taken into account. System workbench for STM32 July release is moving ‘generic’ board support way !

Br,