FreeRTOS: Only one of two tasks are occurring

[KMew]

Hello,

I am utilizing a FreeRTOS system on the STM32H725AGI6 in my software with two purposes:

- Run a task that handles the TouchGFX process to operate an LCD display

- Run a task that handles a BLE process (Which utilizes the

BlueNRG-M0A)

I have tested both processes separately and both work as I intend them to. 

I created the two tasks with the FreeRTOS system and observed that:

- If I comment out the creation of the TouchGFX task in the main.c, the BLE portion works as intended

- If I comment out the creation of the BLE Task, in the main.c, the TouchGFX portion works as intended

- If I run both tasks at the same time, the TouchGFX portion works as intended, the BLE initialization code is run, but the repeated process (MX_BlueNRG_MS_Process()) is never called.

I've included the task initialization and process for both below. Additionally, I've attached my CubeMX configuration for the FreeRTOS system.

I have tried to do the following:

- Increase the cheap size to 35000

- Add osDelay(1) into the TouchGFX Task

- Remove the BLE Task and have the process called as part of a timer interrupt instead

None of the above solutions solved the problem.

I am unfamiliar with FreeRTOS on a deep level, but I suspect it is related to memory management and/or the priority system of the tasks, but I am unsure of how to prove this and diagnose this problem. The reason I suspect it's a memory issue though is that I'm running at 94.61% of Internal RAM usage. I allocate the entire TouchGFX task and 480x272, RGB565 array in the Internal RAM, which is why it's so heavily used. 

I attached my BLE portion of the code so that the MX_BlueNRG_MS_Init() and MX_BLUENRG_MS_Process() can be reviewed to try and get a better understanding. 

Can someone please help me get some insight on this issue?

void BLE_Task(void *argument)
{
  /* USER CODE BEGIN BLE_Task */
	MX_BlueNRG_MS_Init();
  /* Infinite loop */
  for(;;)
  {
    osDelay(1);
    MX_BlueNRG_MS_Process();
  }
  /* USER CODE END BLE_Task */
}

void TouchGFXHAL::taskEntry()
{
    enableLCDControllerInterrupt();
    enableInterrupts();

    OSWrappers::waitForVSync();
    backPorchExited();

    /* Assert display enable LCD_DISP_CTRL pin */
    //HAL_GPIO_WritePin(GPIOA, GPIO_PIN_2, GPIO_PIN_SET);
    /* Assert back light LCD_BL_CTRL pin */
    //HAL_GPIO_WritePin(GPIOA, GPIO_PIN_1, GPIO_PIN_SET);

    for (;;)
    {
    	//OSWrappers::taskDelay(1);
        OSWrappers::waitForVSync();
        backPorchExited();
    }
}

[JTP1]

Hello

I'd would probably try to reduce RAM usage to see does it makes any difference. You can for example reduce vertical resolution in half and then maybe even move framebuffer to unused 128K block.

Since you earlier had problems with statically allocated framebuffer, it is likely that this problem is also related to memory usage. As long-term solution, you could consider to use partial framebuffer.

Br J.T

[KMew · Accepted solution]

Thank you JTP.

I did discover what is was. It was a two layer problem.

First off, my FreeRTOS ticks were too frequent that we were only in the FreeRTOS idle task for about 8-9% of the tick and the TouchGFX task was telling the OS that it is it's turn before the initialization of the BLE was properly completed, causing it to get stuck in the hci_reset().

Secondly, I forgot to enable the MPU cache properly for the RAM. It was not set as cacheable.

Once I did both changes, both tasks were running without any issues on the RAM usage or task calls.