1

Checking THIS answer made me a conclusion that I might do something wrong about FreeRTOS handling. This is how it looks at SWV Console

enter image description here

Code it self is nearly freshly generated by CubeMX without any spectular changes about handling the task's (it contains infinites loop's) with osDelays equal to one second.

enter image description here

  • Shouldn't it never get into main function again?
  • What might be the problem?

freertos.c enter image description here

CubeMXenter image description here

enter image description here

Multiple errors reported.

1) Failed to execute MI command:
-var-create - * vApplicationStackOverflowHook
Error message from debugger back end:
-var-create: unable to create variable object

2) Failed to execute MI command:
-var-create - * vApplicationStackOverflowHook
Error message from debugger back end:
-var-create: unable to create variable object

3) Failed to execute MI command:
-data-evaluate-expression vApplicationStackOverflowHook
Error message from debugger back end:
No symbol "vApplicationStackOverflowHook" in current context.

4) Failed to execute MI command:
-var-create - * vApplicationStackOverflowHook
Error message from debugger back end:
-var-create: unable to create variable object

5) Unable to create variable object
  • For the start: What does `osKernelStart` return? Also be aware, that `osKernelStart` is a CMSIS defined API call, not FreeRTOS specific. So mechanis within that function might differ from FreeRTOS' default behaviour. – junix Jan 28 '21 at 10:41
  • 2
    Are you using FreeRTOS directly or CMSIS-RTOS?. CMSIS says "When the CMSIS-RTOS starts thread execution with the function main this function resumes thread switching. The main thread will continue executing after osKernelStart.". Returns "osOK: the RTOS kernel has been successfully started." – Jose Jan 28 '21 at 10:43
  • 2
    Maybe something is causing a hardware reset? – Tagli Jan 28 '21 at 10:49
  • So FreeRTOS itself dosn't come back to the main function after initialize the schedular but the CMSIS os does even with FreeRTOS on the board? :o meaning what you telling me that behavior seen on the pic's are desirable –  Jan 28 '21 at 11:00
  • 1
    @Jose irrelevant. It is freeRTOS with stupid ARM API. After sheduler start the rest of the main is not executed. – 0___________ Jan 28 '21 at 11:02
  • @OskarGarczyński no it does not. As I wrote it is normal freeRTOS with some stupid macros and nonsense functions from ARM. Absolutely useless. Do not listen to people who never used it – 0___________ Jan 28 '21 at 11:02
  • @Tagli you are right. It simply restarts. And unfortunately it is not possible to resolve without access to the Oskars computer. – 0___________ Jan 28 '21 at 11:06
  • That's confusing rn folks because Iam using CMSIS v1 generated from CubeMX as shown on attached picture (edited) –  Jan 28 '21 at 11:07
  • @OskarGarczyński find `vApplicationStackOverflowHook` function and put a breakpoint there. – 0___________ Jan 28 '21 at 11:08
  • 2
    @OskarGarczyński CMSIS os from CUBE is a normal freeRTOS with some useless macros and a few functions on top from ARM. Nothing to be confused - freeRTOS documentation is important. BTW I would scrap all that ARM nonsense and use native freeRTOS API – 0___________ Jan 28 '21 at 11:10
  • suprisnly watching vApplicationStackOverflowHook gave me some news that wasnt expected. Pic has been provided at the end of the question above –  Jan 28 '21 at 11:45
  • deleting osDelay(1000); does not bring the program to the main debug printf, what does that mean? –  Jan 28 '21 at 11:59
  • @0___________ I do think that it is important the different between FreeRTOS and CMSIS, they are different things. Regarding the scheduler, main thread is not the same than main function, documentation is clear about that. And yes, it can return to main function if the calling fails. – Jose Jan 28 '21 at 12:07
  • 1
    @Jose I think that you do not use it. This implementation of CMSIS RTOS is based on freeRTOS **and** the `osKernelStart` simply calls `vTaskStartScheduler()` which does not return. If you do not know how does it work in practice, do not discuss the issue ! vTaskStartScheduler() may fail when there is no enough memory. But it is not the issue here as other task are executed (so the sheduler was started). – 0___________ Jan 28 '21 at 12:39

0 Answers0