Custom STM32F469 board driving DSI LCD exhibits random horizontal shift.

[RobNewbury]

I have been using a STM32F469i Disco board to interface with a 800x800 LCD in MIPI DSI video burst mode. In order for this to work from the DISCO board, I have an adapter PCB to connect from the DISCO board to the LCD.

It took a while to get going, but the setup with the custom LCD and DISCO board is working fine.

I have recently moved to a custom board; I have intentionally made the video dependent aspects of this board the same as the disco board so that I can run my software on either the disco or the custom board without making any changes.

The custom board sometimes exhibits odd behaviour when rendering from the SDRAM via the LTDC.
Enabling the test colour bars from the DSI always display ok without any problem.
From SDRAM/LTDC, the horizontal start point shifts from the left side of the display to some arbitrary location across the width of the display. This occurs randomly, it can be running for hours and remain stable, other times it may shift once, then be stable for a time and maybe shift again later. It seems to occure more often following a reset, sometimes with repeated horizontal shifts. Once settled it seems to remain settled for long periods. On occasion the LCD will revert to black, however this is the exception rather than the norm.

I have run a memory test and it's not the SDRAM becoming corrupted. I don't rule out FMC timing issues, so I have checked the FMC timing configuration. As I am using the same SDRAM as that on the DISCO board, I wouldn't really expect these timings to be wrong.

Any ideas would be appreciated.

This is the custom board.

   

This is the DISCO board with LCD interface

[KDJEM.1]

Hello @RobNewbury ;

Please make sure that the SDRAM clock frequency does not exceed the maximum supported value. You can fin the maximum FMC_SDCLK in the datasheet.

Also, I recommend you to start with verifying SDRAM timing and LTDC configuration, then proceed to signal integrity checks.

For that, I advise you to AN4861 for detailed recommendations on LTDC and SDRAM configurations, including optimizing framebuffer fetching and addressing potential pitfalls

I hope this help you.

Thank you.

Kaouthar

[RobNewbury]

I have spent some time now trying to track down this problem of random horizontal shift, but I have not found a solution.
I would be very interested to hear from anyone who has experienced similar behaviour.
I have now observed this happening on the DISCO board, though it is far less frequent than on the custom board, but likely does point to some inherant wekness. 
The DSI test colour bars are rock solid, so I am ruling out the DSI interface and display configuration. This leaves the LTDC, DMA2D and SDRAM as potential sources of the problem. I disabled the DMA2D and the problem still occured, so that can be ruled out too.
I have checked all of the following:-

1. SDRAM bandwidth (40% margin with SDCLK at 72MHz @ 3.3V)
2. LTDC bandwidth for 16 bit colour, 1 layer, LTDC +DMA2D. (45% margin with pixel clock at 43.8MHz)
3. LTDC setup and framebuffer stride (AN4861 para 5.5.2)
4. FMC setup as per https://community.st.com/t5/stm32-mcus/how-to-set-up-the-fmc-peripheral-to-interface-with-the-sdram/ta-p/49457
5. Selected FMC SDRAM Common Burst Read (AN4861 para 5.5.2)
6. Setup double buffering for second buffer to start at SDRAM Bank2. (AN4861 para 5.5.3)
7. Tested the framebuffer SDRAM by writing a colour bar pattern, waiting for the horizontal shift to happen and then reading back the SDRAM content which is correct.
8. There are no LTDC error interrupts (i.e. no FiFo underrun or any other errors)
9. To rule out EMI affects, I added a copper screen tightly coupled to 0V around sensitive areas of PCB (MCU & SDRAM).
10. The SDRAM write operations loading is low, all screen updates are stopped, except when manually changing between screens.

My own analysis tells me that following a VSYNC the LTDC framebuffer address counter is not always starting at an address corresponding to the left side of the screen. This theory is re-enforced because writing a white screen with a cross at the centre does not result in the horizontal porch areas being seen so they must still be in the correct positions relative to the screen. And yet the image has moved, this tells me that the problem must be as a result of the LTDC reading at the start of each line from a frame buffer address that does not correspond to the line start.

[RobNewbury · Accepted solution]

The problem turned out to be with the crystal oscillator on the custom board, however the DISCO board which used the same external 8MHz Xtal has on occasions exhibited the same problem. The application is automotive; welding was taking place on one occasion when visiting the customer and then the DISCO board repeatedly exhibited the problem. So likely electromagnetic interference exasperates the issue. 

Changing the external xtal for a TCXO has fixed the problem.

My theory is that the layout of the custom PCB was not optimal in the area of the Xtal, however it was not horrendous either, the trace lengths were short and without meanders, however there was no ground plane below the xtal, a groudplane is present under the Xtal on the DISCO board. 

DSI video mode applications require both the pixel clock (applied to the LTDC) and the DSI lane byte clock to be in sync with each other. This should happen because both the PLLSAI and PLL DSI are phase locked to the HSE clock (from the xtal). If however the HSE clock exhibits jitter, then it is likely that the synchronism of PLLSAI and PLL DSI will momentarily be lost leading to sync issues which in my case resulted in the screen image slipping to the right.