Code is getting stuck at vPortRaiseBASEPRI after using Touchgfx

[Chandan Bhatia1]

Hello, I have created one basic project with STM32F746ZG and touchgfx. When I ran my code, In starting only its getting stuck at freeRTOS function vPortRaiseBASEPRI. After debug I found that code asserted at below line of function xQueueSemaphoreTake of queue.c.

/* Check this really is a semaphore, in which case the item size will be

0. */

configASSERT( pxQueue->uxItemSize == 0 );

This function is getting called by OSWrapper.cpp function tryTakeFrameBufferSemaphore. Here we are trying to take Semaphore "frame_buffer_sem". So in simple words value of frame_buffer_sem. uxItemSize is odd like 480.

When I debug more, I found during initialization(OSWrappers::initialize) of Semaphore has all correct values but seems like after sometime its getting all data corrupted.

I am really not sure how heap memory is getting corrupted as I just generated code from touchgfx and STM32CubeMX. My heap size is 32768 bytes.

Below are the screen shot of memory allocated for Semaphore "frame_buffer_sem"

After Initializing:

At function tryTakeFrameBufferSemaphore call:

Note : 0x200004c0  is address of Semaphore "frame_buffer_sem" .

Clearly heap data is getting corrupted.

Below is the stack level

Any help?

[Chandan Bhatia1]

i m using version 5.4.0. For me also I need to open addition touchgfx software.

[Chandan Bhatia1]

@Alexandre RENOUX​  I doubt if its 64HZ. I ran small test, I was toggling GPIO pin whenever function Model::tick() is called. GPIO was togging after every 40 mill seconds means refresh rate is 25HZ.

Also got updated datasheet of another Display. We should give as below in CUBEMX. Correct ?

40MHZ clock

Synchronization with horizontal as 1 and vertical as 3,

horizontal back porch 46, front porch 210

vertical back porch 23, front porch 22.

Thanks

[Alexandre RENOUX]

Hello,

When you refer to Model::tick(), it's the frequency of the TouchGFX Framework not of the display. They are different even though they should match as best as possible. For instance, if your MCU struggles with heavy graphics computation, the rendering might be longer than 16.6 ms, which will postpone the tick accordingly (I believe it will then wait for the next tick consequently lowering the framerate from 60 Hz to 30 Hz).

Regarding the datasheet, for the porches you are correct. For the rest, I don't know. I'm not the display provider and they are using various names which I understand it's not very clear, but that is the same for me.

/Alexandre

[Chandan Bhatia1]

Thanks, I am facing one issue, Sometimes display works fine but many times there is no display or display image is rolling from top to up in circular way.