TouchGFX DSI video mode issues

LBaga.1 · ‎2021-03-23

Hi ST community,

as others in the forum, I'm trying to work with TouchGFX on a display in video mode.

I started form the LCD_DSI_VideoMode_SingleBuffer with the purpose to have the Video Mode working on another display (based on st7701s controller). This was easy done.

Before trying the new display with TouchGFX, I want to make an intermediate step and have the DSI Video Mode working with TouchGFX with the STM32F469I-DISCO board original display.

I'm testing it with this simple screen:

I get an image which has pixel rows shifted a few pixels on the right with respect to the previous one.

I suspected some sort of LCD synchronization problems, but if I fill the framebuffer with some "for" loops with color values, I get the expected pattern (no skew). This confirms that the LTDC and the DSI Host in video mode seems to be correctly set-up (same setting as same settings as LCD_DSI_VideoMode_SingleBuffer).

If I look at the framebuffer with the debugger (memory view), It indeed contains "stripes" of colors, instead of having 4 rectangular regions. This confirm that is it not an issue from trasferring from framebuffer to display, but the framebuffer content itself is wrong from the beginning.

Note that colors are correct. I tried with other colors (not full red, blue or green) and I still get the stripes, but with the correct colors.

I 've finished my ideas on what to check...does anyone can figure out what could be the cause and suggest what to check?

I work with singleframe buffer at 0xC0000000 (800x480), rgb565, display size 800 x 480. LDC frequency set at 27,4 Mhz

Thanks in advance,

Luca

MM..1 · ‎2021-03-24

Try check your display and image orientation 0 vs 90 and for testing add text area and box to screen

LBaga.1 · ‎2021-03-24

Thanks @MM..1 for the suggestion.

I tried with coloured text on the rectangles:

With the previous settings, I get the same skewed pattern, with skewed text. The color of the skewed text matches with the background.

Chosing portrait orientation on TouchGFX, seems to be even worse:

I also tried:

Double buffer. Same result.
Slowing down lcd clock. Same result.

😬

More ideas?

MM..1 · ‎2021-03-24

Maybe you dont understand me, You use test image png? You add texts to image? You dont set image orientation not screen orientation.

Add text as TextArea | TouchGFX Documentation

Set layout rotation 90 manualy on image

Alexandre RENOUX · ‎2021-03-24

Hello LBaga.1,

First I want to thank you for being complete and detailed in your explanation. Unfortunately, this does not happen that often on this community so I like to point it out when it's done properly.

If as you said, the framebuffer is corrupted from the start means that this is not related to your display interface. If you were using normal DSI mode, the problem would still be there in my opinion. Can you try reverting to normal DSI mode and see if it changes something ?

The fact that double framebuffer does not help is also peculiar. You are using boxes so it cannot be a Flash issue.

This is indeed a strange problem and I don't have the solution now. Maybe it's related to rotation as MM..1 mentioned.

Do you confirm using the F469-DISCO board ? Also, if possible, could you enclose your project ?

/Alexandre

LBaga.1 · ‎2021-03-25

Hi @MM..1 ,

the png you see is just a screen capture of the TouchGFX designer window. All you see was created with boxes and texts were TextAreas.

LBaga.1 · ‎2021-03-25

Thansk @Alexandre RENOUX .

I have the STM32F461I-DISCO board. I'll enclose the project after this message.

I did some more investigations and I think I can you give some hopefully useful hints for better undertanding.

I believe is not a rotation issue, but something related on the width of the framebuffer settings somewhere.

The test I made is the following and correspond to the project I'm sharing:

1) a for-loop to fill the framebuffer (800x480)x rgb565) with 0xABCD, graysh colour, but easy recognise pattern in memory.

2) Start TouchGFX task, with a specific screen: all green, except:

one vertical white line (0xFFFF) on the far left of the screen, 4 pixel wide. (this was actually a box with 4 pixel width).
one vertical black line (0x0000) on the far right of the screen, 4 pixel wide. (this was actually a box with 4 pixel width).

Purpose of this was to have a easy way to recognise start and stop of a line in the framebuffer.

3) Check the framebuffer in memory view for the above patterns.

Results:

row = lcd line.

Start Address, Stop Addres are the expected offset addresses of start and end the line with respect to the framebuffer base (0xC0000000).

Act. Start Address, Act. Stop Addres are the actual offset addresses of start and end the line with respect to the framebuffer base (0xC0000000), obtained by looking for the white and black patterns.

Delta Star, End is the difference in bytes between expected and actual.

+-----+------------+----------+-----------------+--------------+-------------+-----------+
| row | Start Addr | End Addr | Act. Start Addr | Act.End Addr | Delta Start | Delta End |
+-----+------------+----------+-----------------+--------------+-------------+-----------+
|   0 | 0          | 63E      | 0               | 63E          |           0 |         0 |
|   1 | 640        | C7E      | 680             | CBE          |          64 |        64 |
|   2 | C80        | 12BE     | D00             | 133E         |         128 |       128 |
| ... |            |          |                 |              |             |           |
| 478 | BAB80      | BB1BE    | C2300           | C293E        |       30592 |     30592 |
| 479 | BB1C0      | BB7FE    | C2980           | C2FBE        |       30656 |     30656 |
+-----+------------+----------+-----------------+--------------+-------------+-----------+

Conlcusion:

All lines are complete, ie. starts with the 4 white pixels and end with the black 4 pixels BUT...each subsequent line starts 64 bytes (i.e. 32 pixels) after the

previous one, accumulating a delta between expected and actual start address and leaving 64 bytes of the framebuffer in between two lines untouched, infact the 0xABCD patter, which was initially contained in the framebuffer, can be seen.

Can you or somebody else in the forum point to the reason for that?.

For clearness, this is the screen prepared with touchGFX designer (white line on the left...not very visible):

An this is the result:

MM..1 · ‎2021-03-26

Try compare your project with this, maybe some numbers you have bad or swapped 480 and 800 ...

LBaga.1 · ‎2021-03-26

Thansk @MM..1 !

I think you've posted that before in the forum...so I had done a comparison before.😉

I did it again anyhow: there are some minor differences (clock speed, small differences in porches values, etc.), but no major differences. If I compile and run, It seems stuck after the horizontal pattern, so it doesn't show the expected screen from touchGFX.

I'll dig more into that.

PS: yesterday I posted some more details answering @Alexandre RENOUX regarding the way the framebuffer is updated. Does that add any useful information.

MM..1 · ‎2021-03-26

Yes you need comment out while(1) or all pattern test. Test is good for check DSI connection and LCD. Porch values is critical, must mathematicaly coex with DSI values and clock ratio LTDC vs DSI , this is maybe your major trouble.