System Workbench for STM32

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.

Hank

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?

Peter

"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,

Pascale

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?

The solution may exist here:
http://mcuoneclipse.com/2015/03/29/solving-the-8192-character-command-line-limit-on-windows/

But... I'm not sure how it would affect the SW4STM32 toolchain, or if indeed this is already a part of it. Or perhaps SW4STM32 is using an older version of the build tools?

Will have another look in a couple of weeks.

Hi,

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=Documentation

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.git

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
"your_location"\stm32f7_disco_first_wa\stm32f7_disco_first\SW4STM32

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.

Attached is the build log for above project (stm32f7_disco_first)

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. 😊

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.PLLSource = RCC_PLLSOURCE_HSI;
RCC_OscInitStruct.PLL.PLLM = 10;
RCC_OscInitStruct.PLL.PLLN = 210;
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
RCC_OscInitStruct.PLL.PLLQ = 2;
HAL_RCC_OscConfig(&RCC_OscInitStruct);

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:

/* USER CODE BEGIN 2 */
RCC->DCKCFGR1 |= RCC_DCKCFGR1_TIMPRE;
RCC->APB1ENR |= RCC_APB1ENR_TIM7EN;
TIM7->PSC = 10000;
TIM7->ARR = 10000; // 10k * 10k = 100M == twice a second @ 200MHz
TIM7->DIER = 1;
TIM7->CNT = 0;

NVIC_EnableIRQ(TIM7_IRQn);

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