cancel
Showing results for 
Search instead for 
Did you mean: 

TouchGFX Lined Output on RGB Display

StephenG
Associate II

Hello,

My TouchGFX application is outputting a static image in the GUI wrongly and I am unsure where the error stems from.

Board: STM32H747I-DISCO

Display: Innolux G057VCE-TH1   (640wx480h RGB666)

Without TGFX, I am able to output a chosen static image array correctly, and when it is on external memory. Thus, I believe my configuration for the LTDC and FMC is correct. When using TGFX, I set up breakpoints for the LTDC FIFO underrun interrupt handler, and it was never triggered. 

In TGFX Designer, whether I have the orientation as portrait or landscape, and fill it with the image filling the screen, the output is the same.

This project was initially generated from TouchGFX Designer for the discovery board, and I gradually modified it to accommodate this display. An important change was commenting out DSI and old display controller calls (this new screen does not have a controller, it just uses parallel RGB).

When I am debugging, the program does not run into any infinite-while-loop error handlers.

I inspected the generated cpp array of the color bars image and they seem to be fine.

What I notice from the image is that vertical lines are now drawn horizontally and at a slight angle downwards. Instead of gray, yellow, cyan, green, purple, red, blue from left to right, it is now drawing that progression of colors line by line downwards. This is why I suspect that the problem lies in some orientation configuration affecting how the TGFX engine draws pixels to the framebuffer.

1 ACCEPTED SOLUTION

Accepted Solutions

Yes, putting this after the LTDC init functions corrects the image. I still do not know why TGFX adds the 32 pixels of bogus at the end of each line.

 

StephenG_0-1691606764024.png

 

View solution in original post

17 REPLIES 17
JTP1
Lead

Hello

How you have set the display dimensions and color depth when you create project with TGFX designer ? This setting must match your display layout.

Changing horizontal or vertical orientation doesnt help you, problem is 'deeper'. With working configuration you can select any of those and picture is show right (I mean picture is not distorded).

Br J.T

The project was created for the DISCO board, so those settings were not the same. I updated the LTDC and TGFX settings in CubeMX, and those changes are reflected in what Designer shows. Not shown in the screenshots is that the LTDC GPIO speed are all set to very high.

StephenG_0-1691517407730.png

StephenG_2-1691517472161.png

 

StephenG_1-1691517442722.png

 

StephenG
Associate II

Designer showing the right display dimensions:

StephenG_3-1691517590848.png

 

OK. When you do test with setting external image to framebuffer, was it 'real' image or just framebuffer filled with some constant value ? I mean can you really know based on this test that LTDC parameters are correct for your display.

BR J.T

It was me filling the framebuffer location with a constant value. Then I should know that the LTDC can grab data from this area and output what's known to be there.

When I involve TGFX, this will generate the data that ends up in the framebuffer. The LTDC behavior shouldn't be changed with the use of TGFX

The image below was me using the generated image cpp file from Designer as a static framebuffer.

StephenG_0-1691518921902.png

 

Ok, sounds bit confusing..everything seems to be right and tested but  it doesnt work:grinning_face_with_sweat:

What if you set also the display type to RGB 888 from CubeMX. Remember allways generate code from TGFX after  Cube generation, even it would not be necessary this case.

Br J.T

Yes, I am also confused by the traceability of this problem, thank you for the quick replies regardless.

In this case I am not able to change the LTDC output to RGB888 because I don't have the pins available for it (non default pin mapping for what I'm doing). Besides, the screen can only take RGB666. Internally, this should just look like chopping off the internal two least significant bits of each color in the LTDC internal format. The images are being processed in RGB888, and the LTDC does the chopping off of bits at the end by not having anything on those two LSB.

StephenG_0-1691520010244.png

 

JTP1
Lead

OK. Maybe I would repeat manual framebuffer test and try draw vertical line there to make sure it works also and once more confirm that it is TGFX side problem.

I suppose you have allready check the data in framebuffer that its really 24 bit and color bars are set correctly there by tgfx ?

Br J.T

I have already tested the manual framebuffer plenty of times.

However, in the IDE I am not able to inspect memory contents, they are all question marks. When I did not involve the FreeRTOS and TGFX, I was able to inspect memory. So what I know is that the image files generated have the correct data, the LTDC is able to take whatever is in the framebuffer and put it out to the display if the data is correct, but what's left is I don't know the data being put there in real-time.

 

I was able to inspect the leftover memory contents of the TGFX framebuffer location the next time I used a manual framebuffer location, and it appears that there are the same, correct contents. This may be suggesting that the TGFX engine output may be correct.

Manual framebuffer and data:

StephenG_1-1691521795950.png

 

TGFX framebuffer location:

StephenG_0-1691521773729.png