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

Importing Cube example programs: F7-discovery

Hi all

Apologies as I’m clearly being thick but this really should be easy.

I’ve been using Keil and CooCox with the F4 and am just trying to get going with the System Workbench with the F7.

I’ve just got a F7-Discovery Board. In Keil, I can open the Cube example F7 projects (STM32Cube_FW_F7_V1.1.0), build them and load them to the board and everything works perfectly.

With System Workbench I can’t even get the example projects to import.

I’ve followed the instructions for “Importing an STM32CubeMX generated project under System Workbench for STM32” but when I browse to the root folder for the example: STM32746G_DISCOVERY, the project name is greyed out and I can’t select it.

I’ve tried setting all the files in the Cube directory to read/write rather than read-only but that makes no difference.

I’m clearly missing something, help appreciated


Hi Peter,
I have had mixed success with the example projects and that is using the 1.6.0 Cube libraries which support SW4STM32 projects.

For other DISCO boards I have looked at, the example projects are not generted by MX. If the STM32F7 projects are, that is a step forward for ST.

I did notice that all of the example projects come up with the same eclipse project name. Once you load one, eclipse will not allow you to import another project with the same name. You either need to put them in seperate work spaces (I did not try this but think it should work) or rename existing projects befor importing a new one.


Thanks - that solved the greyed out issue but I’m still nowhere near getting anything loaded onto the chip.

I import the project and then when I build it it doesn’t find files like “main.h” which are clearly in the project directory.

There also seems to be the most complicated system to specify how to download the code to the chip. Why can’t I just select ST-LINK as the programmer/debugger and press “download” like every other IDE?

I’m very near to giving up having wasted over 10 hours without even getting a simple program downloaded onto the chip - something that took 5 minutes with Keil.

Can anyone point me at a USEFUL tutorial?


Hi Peter,

I share your pain and probably spent about as much time as you have trying to get the IDE to work correctly. I have had success with some of the projects but not the ones that are of interest. I tried building the “BSP” example project fromt the STM32CubeF7 archive but only got it to compile and not able to download. In general these are the steps I took to build an example project:

1. Erase your entire workspace directory and start from scratch.
2. Open the IDE and right-click in the “Project Explorer” window pane.
3. Select “Import...” and choose “General -> Existing projects into workspace”
4. On the next window choose the “Select root directory” radio button and browse to an example
eg: \STM32Cube_FW_F7_V1.1.0\Projects\STM32746G-Discovery\Examples\BSP\SW4STM32\STM32746G_DISCOVERY to build the “BSP” project
5. If all goes well you should see the project show up in the “Projects” box.
6. Make sure that all three of the “Options” boxes are unchecked and click “Finish”
7. This will load all the relevant files and create the “BSP” project in your workspace.
8. To build the project, from the main menu bar, choose “Project -> Build All”.
9. This will generate the .elf file you will need for downloading and debugging.

The part where I get stuck is creating a debugging session. None of the projects from the STM32Cube7 archive contain any debug configurations so it is a matter of trial-and-error in setting up a debug configuration. For some of the sample projects the following seems to work:

1. From the main menu bar choose “Run -> Debug Configurations...”
2. In the pop-up window ensure that “AC6 SMT32 Debugging” configuration is highlighted
3. On the “Main” tab of the window select the project that you are debugging.
eg. the name of the project will be something like “STM32F476G_DISCOVERY”
4. For the name of the application, browse to the directory containing your .elf file and select that file.
5. Click the “Apply” button to save the configuration. If you want to start debugging click “Debug”

If all goes well you will be taken to the Debug perspective in the IDE where the target will be reprogrammed. The breakpoint will be started at “main()” where you can choose to single-step or run the code. I found that this procedure worked for only some of the projects so your results may vary.

The only IDE I truly had success with is IAR. Unfortunately, most of the demos exceed the 32K code size limitation of the Kickstart version of IAR. I am running the 30-day full license version. My hope is that the state of the tools will improve. The mbed.org website has the same Discovery board available but none of the code has been ported by STM for this board. For now I have put away my board and hopefully won’t regret my purchase. Even the ST-LINK utility from STM doesn’t support erasing and programming of the NOR flash memory on this board. I think a lot of patience is in order :-)

I hope the above helps.

“For now I have put away my board and hopefully won’t regret my purchase”

I think that is the correct course of action - there are only so many hours in the day.

Thanks for your input (didn’t work for me as the workbench tried to find the files in completely the wrong disk location) I’ll also wait on developments

Hello matherp,

Thank you for your feedback. I have tried to import an F7 Discovery example into SW4STM32 and I experienced the same build issue. I found the following workaround : as I suspected the gcc command line to be too long, I moved the example from the SW4STM32 download directory to C:\TMP. This time the build worked.

KInd regards,


Also having problems here. Cannot import an F7 discovery project as the files are broken links.

Tried generating project in c:\cubegen to keep path short after reading above.

Cubemx import works for F4 discovery on same install. Latest cubemx library updates for F7 - currently 1.1.0.

Tried editing the project settings, but it’s coming up as importing ” configuration” as the project name, so something is obviously wrong there.

>>>Different code is generated depending on whether you click on the menu option “Project>>generate code” or the “generate code” cogwheel button in cubemx.

Looking on the file system, my import has not imported any C files, which I can see generated and in the cubemx generation folder. I tried this inside and outside the workspace.

Import works fine for keil.

New F7 disco project works ok from SW4STM32 but then I don’t get the clock configs correct, and I can’t time functions I want to benchmark.

Posting this as the above info got chopped off my last post.

Is this post dealing with importing from a cubemx generated project? Or just a pre-existing example?

I’m having problems generating a project with cubemx, it doesn’t import properly.

However, I’ve nearly got it to build after doing the following:

1. Manually copy the files to the locations required in your eclipse project, so all the source, headers and .S startup files, CMSIS dsp stuff etc.

2. Repoint headers using the “workspace” option to the relevant include directories. The “debug” folder will dissapear when you set up a debug configuration.

3. Delete headers not needed, like for the ‘745 and 756, as we’re using the 746...

4. Delete the IAR and ARM startup .S files, leave the gcc one for the 746.

5. Build it. It nearly works.

I’m having an error where gcc is dropping characters from the object files passed to the linker: (could be a windows problem parsing >8191 chars according to stack overflow post...)

arm-none-eabi-gcc: error: ./Drivers/CMSIS/DSP_Lib/Sourc/StatisticsFunctions/arm_min_q7.o: No such file or directory
arm-none-eabi-gcc: error: ./Drivers/CMSIS/DSP_Lib/Source/FilteringFunctions/arm_fir_sparse_nit_f32.o: No such file or directory

Note /Sourc and /Source folder in path, and also .../arm_fir_sparse.nit_f32.o in the second object.

So that’s where I am. Again, out of time, and off on hols next week. :/ Maybe this will help / spur someone on to find a fix?


Since I have compiled and debugged CubeMX generated projects and around 10 ST examples for 4 different boards, even that I don’t have yet a ST F7 board I was curious to try a project for STM32F7.

As for the rest of the projects generated using CubeMX I have follow the steps described in the documentation “Importing a STCubeMX generated project”, at this link: http://www.openstm32.org/Importing+a+STCubeMX+generated+project?structure=DocumentationQuestion

The build was without errors and the elf file was generated. Attached is a screen shoot after build step - stm32f7_build.

I have also setup the debug configuration (hope that I did not mess up something because I did it without to check the documentation).
On my system, at least the debug process is started but of course at the end fails - no board communication.

If anyone is interested to try to rebuild the project using System Workbench the project is at this link:https://bitbucket.org/csalageanu/stm32f7_disco_test.gitQuestion

CubeMX project is this one: stm32f7_disco_first.ioc
Should be open with CubeMX without problems. I don’t know if CubeMX will update the path for the new pc. So to test only the build step is better to not regenerate the project,
anyway project could be open and inspected.

For build step should be follow the process described in documentation “Importing a STCubeMX generated project”:

- Open System Workbench for STM32. When SW ask for workspace, browse to directory stm32f7_disco_first_wa. This is step 3 in the documentation (see link above)

- After the Eclipse Welcome screen, import the project as following
File >> Import...
Click on “Browse” and navigate to

The projects list is refreshed and should display your project (“stm32f7_disco_first
Configuration”), select it.
Ensure the option “Copy projects into workspace” is uncheck
Click on “Finish” button.

- Build the project

- Check if the debugger configuration is present. If it is present try to debug. If not create
a new one, following the steps described at above link.

I hope this will work, I did’t have time to test it.


Regarding the CubeMX project, I selected Discovery board for STM32F7 and I didn’t change any configuration, so it is the default configuration that came from ST. There are few peripherals that are enabled, but not all. Also seems that most of the Cortex-M7 features are disabled: ART Accelerator, CPU I,D cache, Instruction Prefetch - I let them as it was.

For other peripherals the ST provides examples in the Cube Library. For this board (STM32746G-Discovery):
- 15 examples are provided to demonstrate simple usage of the existing peripherals (ADC, BSP, CEC, DAC, DMA, DMA2D, FLASH, FMC, I2C, LTDC, PWR, QSPI, RCC, SPI, TIM, UART).
- 11 projects to demonstrate simple applications (Audio, Display, EEPROM, FatFs, FreeRTOS, LibJPEG, LwIP, QSPI, STemWin, USB_Device, USB_Host)
- one big demo application- this is the application that came installed on the board.

All this examples and more or less documentation are inside the downloaded STM32Cube_FW_F7_V1.1.0 package. An easy way to locate where this folder is on pc is to go in CubeMx > Help > Updater Settings. Then see what is in input text box named “Repository Folder”. Please note that System Workbench could also download this package but in another place.
On my system is: D:\STM32Cube\Repository\STM32Cube_FW_F7_V1.1.0\Projects\STM32746G-Discovery

From what I seen from F4 library package all those projects are also build for SW4STM32 (System Workbench).

For board STM32756G_EVAL ST provides even more examples.

For my “STM32F429I-Discovery” I was able to compile all examples that I need except 2 application examples.

Thanks for the info. Your steps helped, as I eventually figured out that “copy files into workspace” was the culprit checkbox. I unchecked it. Otherwise you just get a bunch of unresolved includes / files etc.

Also, browse to the MX cube generated folder to find the ELF file for debugging.

So, still had a few problems as I had to include the ...legacy.h hal driver file manually, but am flashing an LED now at least.

As far as I can see as well, the default clock speed is way less that 216MHz (105MHz?) and the internal caches and ART accelerator are off. I’ll try re-generating with those configured and clocks set up etc, and see what I get.

Just mentioning the gotchas above for others.

Thanks for your help. :-)

Glad that you succeed.

Regarding the ELF file, I do the same.

On my projects it was not necessary to include stm32_hal_legacy.h file. Maybe when you will have time you can compare your project with the project that I put it on Bitbucket at this link:
https://bitbucket.org/csalageanu/stm32f7_disco_test.git Question
The project could be Cloned on local pc or downloaded as zip.

On my CubeMX project (.ioc file) the clock is set to 168 MHz (SYSCLK). It was the default value when I created the project for this board. I didn’t want to change something before a test.

Let us know the results of testing to the max clock speed and the result of enabling the L1 chace and ART accelerator.

Just for info: there are some commits to OpenOCD related to F7 series (few days ago). I think those are not in OpenOCD version used by SW.
If you observe something strange while debugging you may want to look at this changes.
For reference here is the link: http://openocd.zylin.com/#/c/2940/Question,
and the changes are:
stm32f2x.c: Add STM32F74x handling - Aug 27
stm32f2x: Add memory barrier needed for STM32F7 flashing - Aug 19

IMO flashing a LED on such “very high-performance MCU” is a big step. There are no other microcontrollers with such an impressive resources and peripherals.
From what I know no other microcontroller has an L1 cache memory.

Here is an article on eetimes about Cortex-M7: ARM Cortex-M7: Abundance of Memory or Not Enough?Question.

Ok, so I looked over your git project (Thank you!) and compared your .ioc and my .ioc, for default projects. I text diffed with pspad and the only real differences are the project names.

So, your ioc project says to set up the RCC with 168MHz, and what actually happens in your main.c in the SystemClock_Config() function, is the following:

RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;
RCC_OscInitStruct.HSIState = RCC_HSI_ON;
RCC_OscInitStruct.HSICalibrationValue = 16;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
RCC_OscInitStruct.PLL.PLLM = 10;
RCC_OscInitStruct.PLL.PLLN = 210;
RCC_OscInitStruct.PLL.PLLQ = 2;

I have that as well. So from the above, we can see it uses the high speed internal oscillator, divides the 16MHz by 10, multiplies 210 to give 336 and divides by two to give the final 168MHz sys clock. Same with mine.

What I’ve done since is set the clocks to use the external crystals and used 25M / 25, *400, final div by 2 to give a 200MHz sys clock, set up in the nice graphical clock config page in cube MX. :-)

So, in my main.c:

TIM7->PSC = 10000;
TIM7->ARR = 10000; // 10k * 10k = 100M == twice a second @ 200MHz
TIM7->DIER = 1;
TIM7->CNT = 0;


TIM7->CR1 = 1;

So just set the timer prescale bit RCC_DCKCFGR1_TIMPRE in the (Direct?) clock config register, to ensure timers get 200MHz sys clock, not APB1, then configure your timer to interrupt and obviously code your interrupt routine as well to indicate / do something.

All the above was basically to check the clock config was right and peripherals working / dubuggable and running at the desired speed. Another 16MHz is for another time maybe ;)

I’ve yet to test the maths capabilities wrt cache and clk speed. Maybe this has gone a bit OT but I’ll put details in a fresh post and report back...

Thank you for the informations.

200MHz is quite fast for a microcontroller