2019-08-22 02:52 PM
I've built a PCB based on STM32F746NG Disco Board, upgraded to a better MCU that suports higher LCD CLK frequencies exactly to drive a 1024x768 LVDS display(the board has a LVDS connector), but even if i met the exactly conditions to run a 1024x768 resolution ocourrs a lot of sync problems on the display, strings, images cannot be rendered on screen successfuly. I've executed a test trying to draw a yellow circle on the center of the screen, the image has the right colors, but the pixels are all dispersed and over the place, shaking vertically and horizontally, meaning Sync problems, even if all is correctly set and cheked by using a oscilloscope to measure the frequencies, what could be causing these problems?
2019-08-22 03:04 PM
The settings are wrong.
The bus is over contended.
The memory bus is only 16-bits wide.
Review the pixel clock, check the horizontal lines totals. Check memory bandwidth.
2019-08-22 06:13 PM
Pixel Clock is 65MHz, the default 1024x768 timings are correct(HSYNC HFP HBP VSYNC VFP VBP), i've checked it by using a oscilloscope and they were correct also, the STM32F746NG DISCO board already has a 480x272 LCD-TFT display attached to it, it works perfectly if i set it's timings correctly, but a 1024x768 LVDS it goes all flickery and pixels are all over the place, if i put a 1024x768 images you can see where the colors should be and everything but it very glitchy.
How should i check the horizontal lines totals? and the memory bandwith? i'm putting the framebuffer on a 8MB external SDRAM on-board, how should the memory bandwith affecting it?
i should remind that this board has DMA2D and LTDC enabled, it would cause a problem?
2019-08-22 06:16 PM
My approach is generally to unpack and decode the register settings. The clock and PLLs from the RCC, and the display from the LTDC.
You should be able to print out all the clocks, frequency and bandwidth expectations, and you need to compare those with the specs for the display.
Review the sync signals on a scope or logic analyzer.
Alternatively feed back signals to TIM inputs and measure/time them against the processor's timebase.
If images don't render properly, you need to check the size/geometry parameters. Paint bars in the frame buffer manually by stepping by the line size.
2019-08-22 08:38 PM
You'd do the math on how much data you are moving, and how quickly that would go across the assorted memory buses, at the cycle counts/widths you've programmed into all of them.
Similarly on the video side.
Benchmark how long it takes to read the memory, with/without the video running.
Video has hard delivery dead-lines, if you miss them the display is going to rip and tear, data will display in the wrong places.
How wide is your SDRAM data bus?
2020-01-13 06:09 AM
@VOliv.2
Did you get this working ? I want to do the same thing …..
R