Kernel not starting

[DK.9]

Hi all,

I am pretty new to the STM32 world and I have just started to play around with the STM32F429 discovery kit and STM32CubeIDE. I am OK with the basic & introductory projects, and I was able to have basic IO operations like LED blinking run properly. 

When I tried to first dig into the FreeRTOS concepts, I realized that I'm having issues with the osKernelStart() call taking place in "main.c". (If I comment out this line, the code builds and runs ok "enough" to blink LEDs.)

To make sure that my own code is not affecting the behavior, 

1) I started a clean STM32 project using STM32CubeIDE, 

2) modified no config at all, 

3) directly generated the code

4) built the project

5) started a debug session

6) Debugged the code using "Step Over" 

When I hit the Step Over again when it's on the line where the osKernelStart() is being called, the debugging step options (Step Into, Step Over, Step Return) are all grayed out but the debug session seemed to continue working.

To better understand the exact point of failure, I re-run the debug session iteratively, by Stepping Over if the code line has been observed to be safe (no graying out of the debug menu items) or by Stepping Into if the line is not safe. The successive list of failure points observed in these iterative tests is as follows:

1) main.c osKernelStart();

2) cmsis_os.c vTaskStartScheduler();

3) tasks.c xPortStartScheduler();

4) port.c prvPortStartFirstTask();

5) main.c osDelay(1); (inside StartDefaultTask)

6) cmsis_os.c line 331: "return osErrorResource;"

I must admit that at this point I have no idea what to check. Can anyone please suggest at least a concept that could cause this problem?

Thanks is advance.

[DK.9]

Tried the same using cmsis_v2 (it was cmsis_v1 in the previous tests) but no difference at all.

[TDK]

> When I hit the Step Over again when it's on the line where the osKernelStart() is being called, ...

> If I comment out this line, the code builds and runs ok "enough" to blink LEDs.

osKernelStart starts the kernel and should not return to its calling function. Are you trying to execute statements beyond that? Did you create a thread? Perhaps show your main.c. There are also many examples in the CubeF4 repository that use FreeRTOS to follow.

[DK.9]

Hi TDK,

Thank you for your answer. I will check examples against the main.c I'm already using.

Regarding your question, no I do not have any user code, it was directly the code generated by STM32CubeIDE. I attached the main.c file for reference.

[TDK]

The code you included doesn't even call osKernelStart. You've also commented out several critical lines. In general, you shouldn't be editing code outside of the USER CODE sections.

I'm sure this is a result of you trying to debug the code, but it's difficult to provide assistance when the provided code has obvious bugs. Perhaps show the code you mentioned in the OP where you are trying to blink LEDs, with FreeRTOS enabled, but it's not working.

  /* Create the thread(s) */
  /* definition and creation of defaultTask */
  //osThreadDef(defaultTask, StartDefaultTask, osPriorityNormal, 0, 4096);
  //defaultTaskHandle = osThreadCreate(osThread(defaultTask), NULL);
 
  /* USER CODE BEGIN RTOS_THREADS */
  /* add threads, ... */
  /* USER CODE END RTOS_THREADS */
 
  /* Start scheduler */
  //osKernelStart();
  vTaskStartScheduler();
 
 
  /* We should never get here as control is now taken by the scheduler */
  /* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {
    /* USER CODE END WHILE */
 
    /* USER CODE BEGIN 3 */
  }
  /* USER CODE END 3 */

> If I comment out this line, the code builds and runs ok "enough" to blink LEDs

I'm trying to understand this. It sounds like you've added code after osKernelStart that you expect to run, which is a fundamental misunderstanding.

[DK.9]

I am sorry for that, I should've shared the unmodified file. Did it now.

This main.c file generates the exact debug scenario I summarized in my original post.

> I'm trying to understand this. It sounds like you've added code after osKernelStart that you expect to run, which is a fundamental misunderstanding.

Actually I have no even a single line of user code in this project. The code has completely been generated by the Cube and I expect the code to launch the OS and do nothing.

If I try to blink an LED by writing my code after the /* USER CODE BEGIN 3*/ line, it doesn't run up till this line (breakpoint not hit). It only does that when I comment out the "osKernelStart()" call, which obviously doesn't help with my design flow but just a debugging trial. (I can also share that main.c version to blink the LED without calling the osKernelStart() if you think it would be useful.)

As you are pointing out, I might be missing some fundamental concept here. But I try to strictly obey the guideline implied by the SDK (no code outside the indicated section).

Thanks,

DK.9

[TDK · Accepted solution]

Since osKernelStart doesn't return, any code after that won't be executed.
To run user code, create a function that does what you want inside of it and create a new thread that runs that function. You can create multiple threads like this and the OS will take care of running each of them successively and according to the priority you've assigned each.
For example, this project creates a thread to toggle some LEDs (along with a timer and some other stuff):
https://github.com/STMicroelectronics/STM32CubeF4/blob/2f3b26f16559f7af495727a98253067a31182cfc/Projects/STM324xG_EVAL/Applications/FreeRTOS/FreeRTOS_Timers/Src/main.c#L63

[DK.9]

I can't thank enough you for this priceless clarification.