Switched to FreeRTOS in Embedded Wizard

Question

Initially we developed the project without FreeRTOS and Integrated it successfully Now the situation arises to switch the project to FreeRTOS and we started to switch the project by

1. set #define EW_USE_FREE_RTOS  1

2.SInce we are using FreeRTOS we change the API for semaphores in ew_bsp_graphics.c and ew_bsp_display.c => osSemaphoreRelease to xSemaphoreGiveFromISR and osSemaphoreDef to xSemaphoreTake

After EwEndUpdate(aViewport,updateRect) method the process is halted.

EwPrintInfo

Kindly note this,

Regards

Sakthi

Answer 1

Hello Sakthi,

have you seen that the original Build Environment for STM32H753-Evalboard already supports FreeRTOS by default? So the easiest ways is to use the settings and implementation as it is provided within that software package.

Can you elaborate what are the differences between your project and the provided Build Environment?

According to your description, it seems that the display update is blocking (waiting) for the next V-sync. Only one update happens, then the main loop stops.

Best regards,

Manfred.

Comments

Hi Manfred,
Thanks for your reply.
In our project we are using our own custom board (stm32H753 controller) and Third party FreeRTOS version 10.0 API . These are the Known things as per my Knowledge kindly specify it If you want any further Info.
Further Info I have created only one task and I am running the thread(EwProcess()) continuously.
Regards,
Sakthi

---

Hi Sakthi,

I assume you are using a double buffered framebuffer (EW_USE_DOUBLE_BUFFER = 1), correct?

Do you have a debugger? Can you check where the GUI task is waiting?

Otherwise: You can add a EwPrint() at the begin and the end of the function EwBspDisplayWaitForCompletion() and check the output on the console. Let me know the result.

Best regards,

Manfred.

---

Hi Manfred,

 

Yes EW_USE_DOUBLE_BUFFER flag is set to 1.

 

Yes I have debuger the and it is haulted at EwEndUpdate() Method Here I attached the screenshot which has call stack for your info

Also I attached the EwPrint() method at the start and end of the function=> Only start of the function EwPrint is printed

EwPrint at EwBspDisplayWaitForCompletion

 

Regards,

Sakthi

---

Hi Sakthi,

o.k. so the entire GUI task is blocked within EwBspDisplayWaitForCompletion(). This means either the semaphore does not work - or the V-Sync interrupt does not work. Can you add some EwPrint() within the HAL_LTDC_LineEventCallback() and check if this is working?

Best regards,

Manfred.

---

Hi Manfred,

 

As per your Instruction I add the EwPrint() in the end of the function, Line Event has printed for n number of times Here I attached the log File .

 

LineEventTest

I suspect in the semaphore because these interrupts are working in non rtos application or maybe I am wrong in this

Regards,

Sakthi

---

Hi Sakthi,

ok - so it seems that the semaphore mechanism does not work. Can you compare your implementation with the original implementation?

Best regards,

Manfred.

---

Hi Manfred,

 

Ok Thanks, As per my knowledge the difference is creating a task in CMSIS as per your examples and we are creating using FreeRTOS API Is there any particular things that I need to recheck Kindly advise meantime I will crosscheck the implementation onceagain

 

Regards,

Sakthi

---

Good Morning Manfred,

 

I cant able to track the issue in my CMake Project but it in stm32CubeIDE the application is running successfully

In my CMAKE project I tested separately whether FreeRTOS is working using simple button Interrupt and its working fine.

Now in my CMAKE project I implemented the same EwInit and EwProcess in a thread I am getting HardFault Error after EwProcessSignal() Function what may be the reason for this hardfault error(Note : Project which worked fine without freeRTOS).

 

 

---

Hi Sakthi,

it's really difficult to give you good advices without seeing the whole software...

Due to the fact that the STM32CubeIDE project is running, you have a working example to compare it with your CMAKE based project.

Maybe you have different linker settings / memory locations within your projects. Or different configuration / compiler settings.

Can you analyze the hard-fault register and the call stack in case of the hard-fault?

Best regards,

Manfred.

---

Hi Manfred,

Sorry for the troubles Here is my HardFault status register values

[16:48:06:573] [Hard fault handler]␍␊

[16:48:06:573] R0 = 24000790␍␊

[16:48:06:573] R1 = ffffffe1␍␊

[16:48:06:573] R2 = 1f3a33ab␍␊

[16:48:06:573] R3 = 2c4␍␊

[16:48:06:573] R12 = 0␍␊

[16:48:06:573] LR = 24000790␍␊

[16:48:06:573] PC = f␍␊

[16:48:06:573] PSR = 8043f9b␍␊

[16:48:06:573] BFAR = 0␍␊

[16:48:06:573] CFSR = 1000000␍␊

[16:48:06:573] HFSR = 40000000␍␊

[16:48:06:573] DFSR = 0␍␊

[16:48:06:573] AFSR = 0␍␊

Thanks,

Sakthi

---

Hi Manfred,

 

Finally found the cause of this issue, In my cmake project I set the code optimization flags for c and cpp to O3 level and that leads to this HardFault Error. So I set the optmization to O2 and its working fine.

 

Thanks,

Sakthi