Problem of porting FreeRTOS to STM32H573I-DK by CubeMX

[EyckHuang]

Hi everyone,

I have a STM32H573I-DK and try to port FreeRTOS without TrustZone to this board by CubeMX but suffered from a problem.

I installed the X-CUBE-FREERTOS, set TIM17 for HAL Tick and SysTick for FreeRTOS.

It will block (or crash?) in vStartFirstTask() after called vTaskStartScheduler().

I have no idea what happened...

Is there problem of my setting ?

Thanks a lot.

[Elatewendy]

Hi,EyckHuang,

  I don't have more details to analyze the problem, but I can provide some ideas. I have also encountered such problems. I created many new tasks, and when I started all of them, a hardware default occurred in vStartFirstTask(). I enabled each task one by one and blocked the others. Finally, I discovered the problematic task. Then gradually enable the functions in the task to locate the specific part of the exception.

  Sometimes it's not an issue with the FreeRTOS, but rather a problem with a certain function, even though it hasn't been called.

 

 

[EyckHuang]

Hi Elatewendy,

My problem has been solved and thanks for your shared.

[mƎALLEm]

---

@EyckHuang wrote:

It will block (or crash?) in vStartFirstTask() after called vTaskStartScheduler().

---

Are you calling vStartFirstTask() and vTaskStartScheduler()?

You don't need to call them as they are already called by CMSIS V1 or V2.

I'm attaching a simple project with 4 tasks each one is toggling a LED on the disco board created with CubeMx using CMSIS V2.

See attachment.

Hope it helps.

[EyckHuang]

Hi SofLit,

I deployed your example on my board, and it worked fine. Then I found what caused my board crash is printf. I used printf to print some logs to UART1.

But it needs to add link option -specs=nano.specs -specs=nosys.specs if compiled by GCC.

Thanks for your attachment.

[emd64]

I experience the same problem.

But it comes from the TrustZone which was enabled.

I disabled it with CubeProgrammer. And it works.  

Linker options are already set.