Can not run FreeRTOS generated with CubeMx on STM32MP157C-DK2

[robsen223]

Hi,

I am working with the STM32MP157c-DK2. All examples are working fine, but now I would like to use custom code. I generated some code using CubeMX for the development board. I used the default settings and enabled FreeRTOS additionally. I compiled the generated device tree file and pushed it to the board. Afterwards, I booted Linux on the A7 processor and launched my compiled FreeRTOS code on the M4 processor using remoteproc. The application crashed.

I used the eclipse debugger to locate the problem: The application crashes, while trying to start the first RTOS task, when calling the function prvPortStartFirstTask( void ) in port.c. As an error message the deugger gives me

Error: stm32mp15x.cpu2 -- clearing lockup after double fault
Polling target stm32mp15x.cpu2 failed, trying to reexamine

I didn´t change a single line in the code generated from CubeMX. Any suggestions why my application crashes? Thank you for your help.

Robin

[Olivier GALLIEN]

Hi Robin,

Trying to duplicate your setup.

-> "I used the default settings"

Is that mean you force code generation with HAL timebase as Systick despite the recommendation warning (popup window) ?

Olivier

[Olivier GALLIEN]

Hi Robin,

Again few question on you setup :

"I used the default settings"

Did you keep OpenAMP enabled?

"I didn´t change a single line in the code generated from CubeMX"

Did you remove or comment call to SystemClock_Config(); in main ?

BR

Olivier

[robsen223]

Thank you for your fast reply, Olivier. ​

Yes, I kept openAMP enabled, because I would like to use it in my future application.

I didn't force the code generation with HAL timebase once the warning popped up. I assigned TIM7 to the M4 context and used TIM7 in SYS as the warning says.

​SystemClock_Config() is called as it should. I didn't remove it.

I​ hope this information will help you to recreate my problem.

[Olivier GALLIEN]

Hi Robin,

"SystemClock_Config() is called as it should. I didn't remove it."

In the MP1 coprocessing architecture, clock tree initialization is handle by A7/Linux part.

SystemClock_Config() should then no more been called on cortex-m4 side.

Please refer to wiki page for complete guidelines :

https://wiki.st.com/stm32mpu/wiki/STM32CubeMP1_development_guidelines

So please, remove the call and let me know

Olivier

[robsen223]

That is an good advice. I didn't know that article before.

I protected the SystemClock_Config() with if (IS_ENGINEERING_BOOT_MODE()), so that it is not called. But I get the same result. It doesn#t work.

Any other ideas what my problem might be?

[Olivier GALLIEN]

Hi Robin,

I don't observe crash on my side doing the same except that I didn't update the DeviceTree on my board.

Actually enabling Middleware like FreeRTOS or OpenAMP does not required specific change in Device Tree.

Can you have a try on default starter package ?

Can you please share each step you have followed to start m4 with remoteProc and how the crash is notified ?

Else, there is a FreeRTOS example provided in the STM32CubeMP1 package.

It's already integrated in the Starter package under /usr/local/Cube-M4-examples/STM32MP157C-DK2/Applications/FreeRTOS/FreeRTOS_ThreadCreation

You can start/stop the firmware directly from this directory :

./fw_cortex_m4.sh start

./fw_cortex_m4.sh stop

Orange led LD7 might blink.

More info here :

https://wiki.st.com/stm32mpu/wiki/STM32CubeMP1_Package

Thanks for feedback

Olivier

[GwenaelT · Accepted solution]

Hi Robin,

There are some knowns issues when using timer as systick with FreeRTOS in production mode (m4 used as copro). It should be resolved in future release.

Once it said :

1 - I would suggest to add following patches in your source code as follow : (patches like git diff way ie (+) to be added and (-) to be removed)

• In file stm32wbxx_hal_timebase_tim.c : (should be stm32mp1xx_hal_timebase_tim.c ...)

- RCC_ClkInitTypeDef  clkconfig;

- uint32_t       pFLatency;

 __HAL_RCC_TIM7_CLK_ENABLE();

+ __HAL_RCC_TIM7_FORCE_RESET();

+ __HAL_RCC_TIM7_RELEASE_RESET();

- /* Get clock configuration */

- HAL_RCC_GetClockConfig(&clkconfig, &pFLatency);

  /* Compute TIM7 clock */

- uwTimclock = HAL_RCC_GetPCLK1Freq();

+ uwTimclock = HAL_RCCEx_GetPeriphCLKFreq(RCC_PERIPHCLK_TIM7);

• In file stm32mp1xx_it.c

- HAL_TIM_IRQHandler(&htim7);

+ if (htim7.Instance != NULL) {

+  HAL_TIM_IRQHandler(&htim7);

+ }

+ else {

+  /* Disable the TIM7 global Interrupt */

+  HAL_NVIC_DisableIRQ(TIM7_IRQn);

+ }

• In file FreeRTOSConfig.h, please make sure to comment the following line like :

/* IMPORTANT: This define MUST be commented when used with STM32Cube firmware,

       to prevent overwriting SysTick_Handler defined within STM32Cube HAL */

-  #define xPortSysTickHandler SysTick_Handler

+ /* #define xPortSysTickHandler SysTick_Handler */

2 - I also suggest you to add the script fw_cortex_m4.sh in your example on target to start / stop the fw in command line as the script seems not provided when generating code from stm32cubemx. You can copy it from any other examples at root path of your example

[Spamfast]

Hi @robsen223​ .

Did you ever get to the bottom of this? I'm having the exact same problem on an STM32MP157AAA on an EV1 board. The debugger tells me it's seen a double fault when I try to execute the 'svc 0' call in prvPortStartFirstTask().

I'm using SysTick for the FreeRTOS tick & TIM1 for the HAL tick.

What's really annoying is that I can get the first task to start - proved by a breakpoint in it - if I comment out one line in some code that runs from the startup routine before entering the scheduler and then it fails if I restore that line. The line is a call of a function that literally does nothing. I can also enable/disable other bits of code that shouldn't have any impact and the fault appears and goes away.

The alignments of the service call handlers and the CPU registers all seem right - the same as when it works - when it's not working.

If anyone (ST Microelectronics, please?!) can explain what's going on or if you found out what the problem was I'd be grateful for the help.

One point to note is that I am using SRAM1 & SRAM2 for code, the top half of SRAM3 & the RETRAM after the vector table for data/bss. The STM documentation for the copressorer/remoteproc says this is allowed and I've got a much simpler program that can use the same linker LD file layout that doesn't exhibit the problem.

Help! :)