Posted on October 04, 2015 at 15:16Hello!
I'm trying to run STemWin/FreeRTOS/HAL on STM32F429IG revision Y at 168MHz.
SDRAM (IS42S16400J-7TLI) connected to FMC controller and runs fine by itself (CAS_LATENCY_3/CLOCK_PERIOD_2/RBURST_ENABLE/RPIPE_DELAY_1).
TFT display (AT070TN92, 800x600 RGB888) connected to LTDC and framebuffer set to SDRAM addresses. TFT clock is 24MHz. With my parameters set to LDTC I can see ~42Hz on VSYNC pin. Frame buffer addresses is 0xd0000000 and 0xd0200000.
OK, forget for now about STemWin, just configure layers and place some data to framebuffer.
ARGB888/ARGB8888 - lost sync
RGB888/ARGB8888 - runs fine.
OK, now I will modify framebuffer contents in main() loop while looking on screen.
ARGB8888/ARGB8888 - lost sync
RGB888/ARGB8888 - lost sync
RGB888/RGB888 - lost sync
RGB888/RGB565 - runs fine...
What? Why writing to SDRAM by CPU breaks LTDC DMA transfers??
OK, let's try to write to framebuffer with DMA2D.
ARGB8888/ARGB8888 - lost sync
RGB888/ARGB8888 - lost sync
RGB888/RGB888 - lost sync
RGB888/RGB565 - lost sync
RGB565/RGB565 - runs fine...
It is going even worse than CPU.
If I turn on STemWin with DMA2D transfers in LCD_DEVFUNC_FILLRECT, I can run only
one layer of
RGB565.
As I understand, DMA2D tries to copy to SDRAM and LTDC cannot get data from SDRAM when needed to paint next line and then sync losts. I can see it as chaotically shifting image to right/left.
What should I do with this? Can I set highest priority to LTDC transfers, so DMA2D and CPU will access to SDRAM only when it is not needed to LTDC?
Maybe I have missed something?
Thanks!
