System Workbench for STM32

I have the same problem with all kind of peripheral. I generate MX code, then import to SW following this http://www.openstm32.org/Importing+a+STCubeMX+generated+project?structure=Documentation
but I can't add a main.h and I can't configure HAL library as a shared library between all project on Workspace, each project has their own copy of driver....

When createing a project, the source files, such as BSP, HAL, Drivers, etc... all come from the STM3232 firmware that was included/distributed with System Workbench, some of which is out of date.

It is much, much, much better to let STM manage the firmware for the processors and let the integrators manage the build environment.

GNU GCC for ARM from Launchpad is maintained, binaries built and then packaged by STM.
Eclipse is built and maintained by Eclipse.
STM32Cube is maintained and distributed by STM and that means it got tested.
The C/C++ Build Envronment is handled by System Workbench.

With each of these groups doing the thing they do best, the tool, System Workbench will rapidly become a better tool to work with.

On another note, I figured out how to get System Workbench to create a bin and a hex file during the same build and I used DfuSe from STMicroelectronics to convert the hex file to dfu file and upload and then convert the bin file to dfu file and upload.

The DfuSe V3.0.4 is broken, it will not make dfu files from the hex or bin files. I used the DfuSe V3.0.3 to successfully do all the above.

"I still had to use a "../../" relative addressing strucutre equal to the on-disk folder/file structure"

Did you try to add the include paths to your build settings? I'm doing this with success everytime I add any new hearder file to the project. The indexer does this for you, and you don't need to provide full path where the file resides.

Regarding CubeMx, I never had luck compiling any piece of code it has generated. I found it much easier and less error-prone to manuall add the libraries you want in the IDE. However, even the newest HAL doesn't work in harmony with AC6 out of the box. Go and create a new C Project, use the HAL Firmward for STM32F429, add the FreeRTOS, Fat, and STemWin components to your project, compile with ARM-none-eabi, and let me know if that worked right away!

I spent two days, too, trying to figure out the linking issue for the STemWin pre-compiled library in AC6. Still the linker complains about certain issues.

I will try to open another thread for the STemWin, hopefully I would get an advice!

Cheers!

I was hoping that this would be a magnet for discussion, but it seems that some folks have been off making use of this Step by Step, thinking thta it came from OpenSTM32 Community.

WRONG!

I documented this process to help people get going and was hoping thta when people ran into issues they would post here and I would then revise my document so that everyone could benifit from the collective input.

In my original post I said,

foment discussion about System Workbench and STM32CubeMX

and that's what you should do people.

Discuss here and we can improve the overall use for others.

I saw a posting about FATFS and anohter about the Configuration change I had mentioned and what else is there?

Thanks for creating your step by step process! I followed it successfully and have a few comments.

1) For whatever reasons, a lot of the peripherals you listed were presented by STMCubeMX as unavailable, Some of the pins were red and I couldn't select them. I thought, based on similar tools, that they would become available as I deselected other peripherals, like it was a pin-mux issue, but they stayed red.

In the end I didn’t need any of the peripherals that were red, so I left them out. That meant that the main.c file contained initialization for devices that I didn’t have code for, so I commented the undefined initialization code out.

2) STMCubeMX downloaded a package during the process, and put it in a default location. When I got to steps 12 and 14, I had to find where that was. For me it was,
C:\users\Michael\STM32Cube\Repository\STM32Cube_FW_F4_V1.5.0\...

3) Between step 17, items ‘i’ and ‘j’, I had to manually add to the “Debug Configurations” dialog, “Main” tab, “C/C++ Application” field the location of the FreeRTOS.elf file. \SW4STM32\FreeRTOS\Debug\FreeRTOS.elf

4) I ran into a series of error messages once I clicked “Debug”.

The final ones were:

Error message from debugger back end:
localhost:3333: The system tried to join a drive to a directory on a joined drive.
localhost:3333: The system tried to join a drive to a directory on a joined drive.

After trying many things, I got it going by reinstalling the ST-Link Utility software. That gave me the correct windows drivers for OpenOCD to talk to the on-board ST-Link V2.

I will address your input from what I have learned (which is not much)

1) After much experimentation with STM32CubMX and System Workbench, I am able to get most of the STM32F4-Discovery pins to go green. When I do this, the STM32CubeMX F4 code that is generated has the requisite support fo these peripherals in it, for intialization and use. I initally commented out a lot or simply deleted to get a working compile.

2) The STM32CubeMX may decide the default install location to be whatever it likes. In any event, one can find it by using the STM32CubeMX Help menu.

3) I suspect that System Workbench is still a work in progress and there are some anomalous happendings every now and then. Sometimes, it has created and filled in the correct information for Debug for me and other times I have to fill it in.

4) I had those same error messages yesterday and was struck by not being able to rid myself of them. I exited System Workbench and restarted, I tried other stuff and then, I unplugged and replugged the USB into my computer and it worked again. I am theorizing that the USB stuff in Windows go confused and that OpenOCD could not figure things out for itself.

Recently, I updated System Workbench, updated the F4 libraries to V1.8.0 and then rebuilt the code with FreeRTOS and VCP with success. And yes, I still had to do all the jumping through hoops to get it going.

If I had the money, I'd own a commercial package in a heartbeat.

Gents, can i have sample project to run
STM32F4 running with FreeRtos and STemWin, I bought STM32429x-Eval bought

regards
terry

I am slowly working my way through the FreeRTOS and USB CDC CubeMX demo.
I am stuck. I can see the function that is receiving my terminal input and the function that is re-transmitting my terminal output. I can print that in the console in the Eclipse/OpenSTM32 combo, using semihosting.

What bothers me is that I cannot figure out who/what is calling the function, CDC_Receive_FS(), most likely an interupt, but from where and how. The other thing bothering me is that this function and the other, CDC_Transmit_FS(), are not running as Threads inside FreeRTOS, so the USB CDC and FreeRTOS are actually running as two seperate programs and not as a cohesive unit, which is what it should be.
Maybe I'm not at the level of understanding to follow this as well as I'd like to?

FreeRTOS and STemWin appears to be good accomplishment to me. Congratulations.

to have cdc revceive_fs you must kick of reception , it will then be called in isr by usb stack when data will come from host, You start the rx by calling

uint8_t USBD_CDC_ReceivePacket(USBD_HandleTypeDef *pdev)

note that many hal driver and f/w will fail with freertos mainly because of usage hal_tick for time out or delay.

systick isr priority is

The function, USBD_CDC_ReceivePacket, is in usbd.cdc.c/h.

This function is called by CDC_Receive_FS in usbd_cdc_if.c.

The problem I have is understanding how CDC_Receive_FS gets called.

The code I am using to look into this is from the STM32CubeMX and STM32CubeF4.

I saw some other code as I looked around for more knowledge that appeared to have something akin to USBD_CDC_ReceivePacket running as a Thread in FreeRTOS, which made some sens to me, but, my knolwedge is limited.

yes you can do that way
in cubemx project you should get Src\usbd_cdc_if.c
with smthg like

static int8_t CDC_Receive_FS (uint8_t* Buf, uint32_t *Len)
{
/* USER CODE BEGIN 6 */
return (USBD_OK);
/* USER CODE END 6 */
}

you can here pass the data to a task using message queue semaphore etc...
up to you and best suite your need
osSemaphoreRelease(xxx);
osMessagePut(xxx....) cpoudl be easier if to pass the buffer address and or size as the message

if you do not mind not using cmsis os layer then you can use direct freertos
xQueueSendFromISR , xSemaphoreGiveFromISR (save some cycle checkign for isr )

I'm doing that in a usb cdc based project wher i'm also re-arming the reception by call USBD_CDC_ReceivePacket(...)
but do only after setup of a new buffer (do not ovewrite data before it get used by the task)
and make sure not to overflow the task queue or lose any data (if using binary semphore).

I will try to be more detailed and precise.

Using STM32CubeMX, I have FreeRTOS and CDC running on a STM32F4Discovery Board.

FreeRTOS is running four Threads that flash the boards LEDs, each at a different frequency.

main.c calls MX_FREERTOS_Init(),

MX_FREERTOS_Init() calls StartDefaultTask(),

StartDefaultTask() calls MX_USB_DEVICE_Init().

I follow this program flow.

I know that CDC_Receive_FS() is being called to receive the data from the VCP, but I do not know how this is happening. Which function is calling this function or which or how is the data received interupt connected to this function?
I am stuck understanding how this function actually gets executed. It's been many years since I did any real work with C (Z80) and I am struggling here. Tere must be some simple piece that I missed. I have read all the USB Device Library manuals and stuff about CDC and VCP and USB from STM, and I don't get it, yet.

As per my experience with these things you must go for the alternative. If you create an empty STM SW project and select that you will use HAL driver.
Also it is added as a shared library and then you be able to use it in the workspace.
But this aproach is not compatible with CubeMX importing project tecnique.

pcb turnkey

CDC receive is called when data arrive on usb (if yu ever started data rececption)
if you want to kwon who call who clik on fucntion " call hieracachy " feature (Ctrl + Alt +H )

All the class and itf and driver indirection make it a bit harder to find
it is called indretcly via USBD_Interface_fops_FS "Receive"
if youn open the struct and find call tree of "Receive"
you will se it get called from
USBD_CDC_DataOut that fucntion is al
that one is again indirectky caledl by "DataIn" field of typedef struct _Device_cb

One that struct "DataIn" is finaly called from usb stack all way down from USB interrupt

see http://s21.postimg.org/lcalr01dz/cdc_data_in.png

Thank you, I will explore this.

I had been doing a C/C++ search for CDC_Receive_FS, hoping that I would see it inside the calling function. I did not find this. For every other function I looked at, I did find it being called from another function, but not CDC_Receive_FS. Hmm... I said to myself, how does this really work?

Many thanks.