DSI strange behavior

[MLamb.1]

Hi st community members,

I'm having some stranges behaviors with the DSI and LTDC, I use these peripherals to communicate with my screen driver. 

The driver need an init to give specific values for some registers, this step is well done.

After that i'm able to write pixel data thanks to the buffer area dedicated to the LTDC peripheral and with the command HAL_DSI_Refresh(&hdsi);.

My problem is that I need to write two times at least in the buffer area before the refresh to write correctly all the pixels data.

For exemple on the picture below, I write a full green screen (2 times needed with 0x00FF00) and after that I restart my program with only 1 write but with less green (0x00AA00). As you can see on the picture I have a partial write, at the right it remain the previous value (0x00FF00).

And when i take an oscillo I'm able to see that the sended data is not always 0x00AA00, I have the previous value 0x00FF00 instead. So after that I have verified the data in the LTDC buffer area, but all seems right (I have always 0x00AA00 in the buffer).

A strange behavior take place when i was reading the buffer : when i have readed all the buffer data in debug mode after my unique write and doing my refresh it's working.

It's like the buffer data is locked sometimes  and when I read this buffer in debug mode it's unlocking.

Hardware :

STM32F769BGT6

DSI :

1 data lane

LTDC :

ARGB8888

color frame buffer start address = 0x20020000

color buff line length = 240

color buff width = 320

If anyone has ever had this problem and can help me.

Thank you in advance.

[MM..1]

You dont explain your DSI config, but in normal situation DSI data and CLK is on around 500MHz and basic scopes cant measure this signals.

[MLamb.1]

I have some screenshots for the DSI config, I hope it will help.

I have a 25 MHz crystal for the HSE that feed the DSI PLL.

My clock is lower because of my clock config, to be able to see the communication with my scope.

[MM..1]

How LTDC DOT CLK ? Why LTDC Layer use ARGB8888 try change to RGB888? This is only for more layers or when need transparency with background color.

[MLamb.1]

I have changed to RGB888 (it changes my memory organisation 24 bits instead of 32 bits) but the same behavior. I need to write two times, to see a correct result.

And when I read the buffer memory in debug mode to check if my data is correct (and it is), it unlock something and after a DSI refresh the data is correct.

I don't understand why I need to write two times or read the buffer memory to get it done.

[MM..1]

DOT CLK? And i use DSI with video mode displays, refresh managed by hw , but one critical condition DOT CLK vs DSI speed must meet i mean in all modes, plus adaptive maybe on some controllers need sync refresh with TE usw...

[MLamb.1]

What do you mean about DOT CLK (vertical hori sync) ?

I dont think it's a synchronisation issue, more like some kind of memory protection.

I tried video mode, it doesn't work.

[MM..1]

You send image clock DSI upper on it exist LTDC clock , that is one pixel (DOT) clk speed.

When i understand how DSI work, then it is filled from LTDC, when you request refresh LTDC start read framebuffer and send it on DOT CLK speed to DSI buff,

then DSI send buff to LCD. When DSI is slower as LTDC then refresh crash on overloaded buffer...

[MLamb.1]

Finally to bypass the problem we only work with memcpy instead of the dma2d, and we read all the buffer destination before the DSI refresh.