FreeRTOS does not run on STM32MP1 (M4 core)

nrg6 · ‎2019-09-05

Board: STM32MP157A-DK1

Situation: I have the release 2.6-openstlinux-4.19-thud-mp1-19-02-20 on the A7 core running. I created a simple FreeRTOS LED app with the latest CubeMX for the M4 core. The FreeRTOS interface ist CMSIS V2. The SYS Timebase Source is TIM7. The DefaultTask toggles LED7.

Problem: In production mode the function osKernelStart returns the osErrorISR state. I figured out that the IPSR holds the value 71 dec.

For test case i included the following code on top of the main.

int main(void)
{
  /* USER CODE BEGIN 1 */
  volatile uint32_t result;
  __ASM volatile ("MRS %0, ipsr" : "=r" (result) );
  __ASM volatile ("nop"::);
  /* USER CODE END 1 */
.
.
.
}

result already has the value 71 when M4 firmware starts. I expect the value 0 because there is no ISR at that time.

If the MP1 is in engineering mode, the scheduler starts normal and result is 0.

Can somebody explain that behavior? Is it possible that the A7 core sets the value in the IPSR?

Thx for your help.

PatrickF · ‎2019-09-05

Hello,

It is unlikely that A7 set IPSR of M4, there is no access of that kind.

71 mean TIM7 interrupt.

Maybe this ticket could help you as there is limitation in current deliveries when using a TIMx as Systick (Btw, why not using the embedded systick timer ?)

https://community.st.com/s/question/0D50X0000AeZfV9SQK/can-not-run-freertos-generated-with-cubemx-on-stm32mp157cdk2

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

nrg6 · ‎2019-09-05

Hey, thx for that hint. I'm not using the Systick because of this warning.

nrg6 · ‎2019-09-06

Hello it's me again, i think there is a misunderstanding here. Because of the warning from CubeMX i'm using TIM7 as HAL timebase, not as a Systick for RTOS. The Systick for the RTOS is generated by the Systick-Timer. This is running perfectly in engineering mode, but in production mode it ends with the osErrorISR state when osKernelStart is called.

osStatus_t osKernelStart (void) {
  osStatus_t stat;
 
  if (IS_IRQ()) {
    stat = osErrorISR;
  }
  else {
    if (KernelState == osKernelReady) {
      KernelState = osKernelRunning;
      vTaskStartScheduler();
      stat = osOK;
    } else {
      stat = osError;
    }
  }
 
  return (stat);
}

I don't understand why there are active ISRs in production mode. Do you have any further ideas?

OlivierK · ‎2019-09-20

Hello nrg6 (SAMSON)

This issue is linked with the fact that in production mode Linux is handling the clocks and interrupts and while the debugger is loading the image, In Engineering mode it is not the case since the M4 is handling this. Moreover the debugger has a different procedure for loading the code depending you are in Engineering or Production mode, that is why the patch listed above applies here for Production mode and allows debugging the application.

Have you applied the patches listed there ? https://community.st.com/s/question/0D50X0000AeZfV9SQK/can-not-run-freertos-generated-with-cubemx-on-stm32mp157cdk2

If you lauch the image using the script available in the StarterPackage available on target at /usr/local/Cube-M4-examples/STM32MP157C-DK2/Applications/FreeRTOS/FreeRTOS_ThreadCreation

./fw_cortex_m4.sh start

./fw_cortex_m4.sh stop

And make a copy of this for your own image, do you still see the problem?

If the problem remains you can refer to the FreeRTOS example provided in STM32Cube_FW_MP1 s/w lib (https://www.st.com/en/embedded-software/stm32cubemp1.html#get-software

Project example available in /Projects/STM32MP157C-DK2/Applications/FreeRTOS/FreeRTOS_ThreadCreation

Best Regards

Olivier

nrg6 · ‎2019-09-23

Hello Oliver,

unfortunately, the patch https://community.st.com/s/question/0D50X0000AeZfV9SQK/can-not-run-freertos-generated-with-cubemx-on-stm32mp157cdk2 can not fix the problem.

I attached my simple CubeMX project with RTOS, OpenAMP and Resources Manager. When i upload the test_rtos.elf file manually and execute it (./fw_cortex_m4.sh start) it is running as expected. I can start and stop it again and again. But the same elf file chrashes immediately in the osKernelStart function when i try to start it via debugger.

I also tried to use the FreeRTOS_ThreadCreation example as base. It is running via debugger, but it also chrashes when i call the MX_OPENAMP_Init function.

For our project it is necessary to use RTOS and OpenAMP. And it is mendatory to debug the programm 8)

If you load the attached project in CubeMX, OpenAMP is not Activated. The state "Activated" is not saved. After reload "Activated" is unchecked. I think this is a bug.

I hope you can reproduce the behaviour with this information.

Best Regards

OlivierK · ‎2019-09-26

Hello nrg6 (SAMSON)

Could you please try with this project. BTW the patches in your project were not applied.

Best Regards,

Olivier

nrg6 · ‎2019-09-26

Hello Oliver,

unfortunately, the patch can not fix the problem. The firmware with the patch behaves like i described in my last post. With the difference, that it chrashes in the hard fault interrupt. Is the firmware running in your development environment?

Best Regards

OlivierK · ‎2019-09-27

Hello nrg6 (SAMSON),

I also experience instability issues like you do. The program sometimes run into hard fault the first time when you enter debug probably due to the way openOCD loads the image with FreeRTOS. This point is currenlty under investigations internally.

However, if you try to set a break point in your code, and load it a second time it works for me. Is it the same for you?

Please pay attention to the fact that when you load the image the second time in System Workbench, there is a popup window asking you the following,, ensure you answer "NO".

Best Regards

OlivierK · ‎2019-09-27

Here's the popup window I was refering to: