Is there a way to disable the automatic default task creation in CubeMx ?

[MEber.10]

We are using CubeMX (incl. FreeRtos) to update our settings.

The problem is that CubeMX will always create a default task in the main. We also tried to remove the following line from the ioc file "FREERTOS.Tasks01=defaultTask,0,128,StartDefaultTask,Default,NULL" but it will automatically rewrite it.

Is there a way to disable the default task code generation ?

Thanks

[char_array]

Latest version of STM32CubeMX is 6.6.1. I just tested it and task creation is still the same. Maybe you have a different MCU? Or maybe the newer STM32CubeIde comes with a different version of STM32CubeMX. An option in STM32CubeMX would be the best, but maybe there still is a possible workaround with a macro. Can you share more details?

[PR.10]

Hi, I use the latest version integrated in cubeIDE not stand alone cubeMX, but I assume is uses common framework. Here is the picture with single task that can not be deleted.

In generated code I can put the #if 0 to prevent to remove the task from being created. Because it is in used code section it will survive the regeneration. However it is completely dependent on generator template which can change with any update so it is no way a solution of the problem. Just a hack for of current version.

/* USER CODE BEGIN RTOS_QUEUES */
  /* add queues, ... */
  #if 0
  /* USER CODE END RTOS_QUEUES */
 
  /* Create the thread(s) */
  /* definition and creation of master */
  osThreadStaticDef(master, master_task, osPriorityNormal, 0, 1000, master_tb, &master_cb);
  masterHandle = osThreadCreate(osThread(master), NULL);
 
  /* USER CODE BEGIN RTOS_THREADS */
  #endif
  /* add threads, ... */
  /* USER CODE END RTOS_THREADS */
 
  /* Start scheduler */
  osKernelStart();

 the processor is stm32g071 but it is probably the same for entire g0 family or eve f0 famil. All of them have just few kB of ram

[char_array]

I don't know if there will ever be a universal way which will work with all future templates. But I came up with an alternative ugly solution that doesn't depend as much on the order of user code sections. Simply redefine osThreadCreate and osThreadStaticDef to empty macros at the top of main.c after the includes and use the freeRTOS api for creating your own tasks instead. If you still want to use the CMSIS API you can create your task in an inline function that is defined above the macros or in a different file so it uses the definitions from the CMSIS header. It builds for me, but I cannot test it as I have a different version of CUBE. Let me know if this works for you.

/* Private macro -------------------------------------------------------------*/
/* USER CODE BEGIN PM */
#define osThreadCreate(a, b) (NULL)
#define osThreadStaticDef(a,b,c,d,e,f,g)
/* USER CODE END PM */

[PR.10]

Creative solution👍, definitely less ugly and fragile than the #if 0. I had to add #undef in front. Fortunately I do not use CMSIS for portability and performance reasons, but since this affects only generated main.c it should not cause a problems elsewhere even if I need to.

#undef osThreadCreate
#undef osThreadStaticDef
#define osThreadCreate(a, b) (NULL)
#define osThreadStaticDef(a,b,c,d,e,f,g)

[JimYuill]

A work-around is to tell STM32CubeIDE to not generate the main() function in main.c.

When FreeRTOS is installed via the IDE, the IDE generates a main() with calls to CMSIS-RTOS functions, to start the FreeRTOS scheduler and a task.
If the calls to CMSIS-RTOS functions are removed manually, they will be recreated the next time that code is generated for the project.

To not generate main(), the IDE's configuration-setting is in the *.ioc file’s "Project Manager" window.
There is a check-box “Do not generate the main().”
I could not find ST documentation for this configuration-setting.

Presumably, you'd need to create main() yourself.
In main(), you'd need to call the MCU set-up functions that the IDE generates in main.c, such as SystemClock_Config(). 

I've tried-out the configuration-setting, “Do not generate the main()”.
But, I haven't tried coding main(), as I just described.

[MAbub.1]

Hi,

Is there any update on it?

We are around 5 years in with an issue affecting many people and still no progress and no response from ST. That is some gold-tier performance by ST. Please give these people a raise they deserve it for their outstanding work. Keep up the good work guys.

[Oskar_H]

Unfortunately FreeRTOS development is discontinued and ST now relies on Microsoft solutions to keep on offering RTOS support with their X-CUBE-AZRTOS packs. If you start a new project from it, after reading some documentation and understanding some basic examples it could be easy. But if you wish to port an old FreeRTOS project to it, forget it !

[MAbub.1]

Hi @Oskar_H,

  I hope you are doing well. If I understood you correctly, It is implied that FreeRTOS is not actively developed and discontinued and therefore ST has to move to other solutions. If this is correct, then, I respectfully have to disagree with this statement. If you see the GitHub repo then you can easily verify that FreeRTOS is very much actively developed and the last release was on 4th March 2023 and the last commit was a few days ago. In fact, Amazon is investing in its development. I also failed to find any mention of it being discontinued during my brief Google searches.

If I am mistaken then please provide a link to the official statement of FreeRTOS discontinuation. Hey, we learn new things every day and I am open to updating my knowledge. 🙂

Putting that aside for a moment and thinking along the lines of providing FreeRTOS legacy support. I don't think it is asking for much to provide a simple boolean option to disable the default task creation. 😉

[Oskar_H]

Hello @MAbub.1 ,

sorry if my message has confused you, let me try to reformulate.

As of now, FreeRTOS is supported in "old" series (F0 to F7, H7, L...) and brought by the firmware packs, aka STM32Cube_FW_XX_V... through STM32CubeMX/STM32CubeIDE and STM32CubeXX through ST GitHub repository.

But the version of FreeRTOS in all these packs is stuck to 10.3.1 from February 2020, with no forecast of evolution, unless I have missed some official communication from ST. That's why I talked about discontinuation.

Now if you want to use the latest FreeRTOS version available (hum, let's say almost the latest one, 10.5.1 from November 2022), then you must install and use the X-CUBE-FREERTOS pack in your project. It comes as a replacement of old FreeRTOS middleware from FW packs and supports only newer MCU series like C0, H5, U5 and WBA.

That means if you have a heavy constraint to use the most recent FreeRTOS version in your application, it will dictate the choice of the MCU series ! Not easy for everyone I guess...

And you are right about the activity of ST FreeRTOS GitHub: it is regularly updated and I think it is this one packaged in X-CUBE-FREERTOS for recent MCU series, but unfortunately not for the older ones...

I hope this clarifies a bit the situation 🙂