I am currently facing the issue with continuously displaying UART data on LCD using TouchGFX

[MPath.4]

I am currently working on the STM32H750VB custom board where 16 bpp RGB LCD Interface is used. After sending the data for couple of times successfully on the LCD screen, it stops displaying the data. On debugging, I found out that it gets stuck on configASSERT( pxQueue->uxItemSize == 0 ) called from xQueueSemaphoreTake(). 

As I am new to freertos and TouchGFX, can you please provide me the insight to find the root cause?

[MM..1]

Without see your code only crystal ball. Seems you use more threaded app and queues. Ball say your trouble is on other place , queue semaphore only wait for handle ...

[MPath.4]

I'm sorry but I'm not able to understand what do you wanna say.

I'm sending you my project.

[MPath.4]

I just don't understand why is it happening please help me.

[Osman SOYKURT]

Hello @MPath.4 ,

I'm not able to open your project, can you zip it and send it again please? (not only the .cproject file).
What do you mean by "it stops displaying the data"? Do you have an entire black screen or is it refreshing data that doesn't work?
Also, did you succeed in configuring your screen without TouchGFX in first place? We have an article describing how to transfer pixel data from the internal RAM to the display, have you seen it?

/Osman

[MPath.4]

hello @Osman SOYKURT 

My screen displayed perfectly the problem is when I send the data from access port through uart it also display it but only for 2-3 times after that when I again send the data it stuck at  "configASSERT( pxQueue->uxItemSize == 0 )" this line when I stop debugging.

And yes I have read that article but for my board I configured LTDC

from   https://www.buydisplay.com/download/ic/ILI6122.pdf 

from this.I send you the file once again.

 

[Panchev68]

There is no source code in the project you sent. So it will be very difficult for someone to answer you.
It is not a good idea to use a semaphore when receiving data over the UART. So it is possible to lose data. Use a queue or stream buffer.

Greetings Bobby

[MPath.4]

This is the link for the project since its size is larger than what is allowed to be uploaded in the forum, you can download from here, but it will expire in 24hrs so please try to see it before that.

https://we.tl/t-R4AgLXgNCb 

And I have used a queue in the freeRtos after that also it shows a issue. 

[JTP1]

Hello

Seems that you are just defining pointer to your structure

 

 uart_Data *uart_Struct;

 

but never allocate memory for it ?

Thats maybe to root cause of your problems. You can add the memory allocation or just make it static by removing '*' on both declaration (main.c and model.cpp).

then probably this line on model.cpp

 

if (osMessageQueueGet(uartQueueHandle, &uart_Model[10], 0, 0) == osOK)
should be
if (osMessageQueueGet(uartQueueHandle, &uart_Model, 0, 0) == osOK)
or 
if (osMessageQueueGet(uartQueueHandle, uart_Model, 0, 0) == osOK)
depending how you will improve the uart_model- stucture declaration

 

Maybe this helps you forward :thumbs_up:

[MPath.4]

Okk thank you @JTP1 

I try it and get back to you later.

 

[MPath.4]

Hello @JTP1

I tried what you said without using '*' but it didn't work the problem remains the same.

I send you the flow of it I hope it will help you to understand the problem.

[JTP1]

Hello. Test with these, I little bit fix to stucture handling on put and get queue. And remove continuos initializing of HAL_UARTEx_ReceiveToIdle_IT at DefaultTask. Since I cant run your code it cannot be verified it 100%.

If its still hanging, try to comment out putting messages to queue, retrieving from queue etc until you find which operation is causing the problem. Your principle of using queue's should work fine since I build as practice a simple serial terminal on the TGFX which shows received strings from uart with queue from main.c. It also sends some test strings from UI button handler to model and then to other os process with TX queue.

[MPath.4]

I tried commenting out  the queues messages and  check it using debug the problem remains the same and please check the Semaphore once .I send you my project again.

https://we.tl/t-Ry6AUdzmPa 

[JTP1]

Hello

Seems that your framebuffer needs 768 000 byte (800x480x2 byte(16 bit)) and you have place is it 512Kbyte area in SRAM (starting from 0x24000000) so its overflowing. Maybe you could reduce Y resolution so that it fits in 512 K and see does it help to the lock ups.(or use partial framebuffer or reduce color count to 256).

[MM..1]

Try start over. 1.Is your code real multithread? 2. Is your MCU real multicore? 3.Is your data uart used only on screen show? usw...

Real use of queues semaphores is required only when your 1. YES 2. YES ...

If i good rememmber UART examples use model get queue data and ISR send queue data. Here cn exist two situation A. Your buff between two model gets is ok filled B. is overflowed

Try STM32 UART Ring Buffer using DMA and IDLE Line - YouTube

 

[MM..1]

Display size isnt problem , segments is addr continuos... Your issue is chaos in uart .

Primary 

 uart_Data *uart_Struct;

secondary no size checks...

[MPath.4]

After that I changed it here. But the problem did not solve. 

Please check this.

[MM..1]

Try this better example, but too dont full clear Riverdi STM32 Display #3. Send data from UART to UI (controllerstech.com)

Primary i mean this uart_Data *.. is ok , but is local for func where queue is used. Real memory is created with call Message Queue (keil.com)

good is create queue for minimal 2 elements and check if is created ok.

FreeRTOS Tutorial #5 ->Using Queue » ControllersTech

[MPath.4]

Hello @MM..1 

I have made some changes still the problem is same but now it stuck in this line 

configASSERT( !( ( pvItemToQueue == NULL ) && ( pxQueue->uxItemSize != ( UBaseType_t ) 0U ) )