DISCO-F746NG LCD rapid draw to screen location causes a visible glitch

Skevitj
Fri, 27 Mar 2020 06:45:43 +0000
Boards

Hi All,

I’ve run into a LCD glitch that’s completely stumped me:
I’ve made a custom board based on the STM32F746ZG, a IS42S16400 SDRAM and RK043HR005-CTG (Same supplier as used on DISCO-F746NG, but 800x480. Similar timings, but obviously a much larger active area and clock).
Drawing to the screen is done via double buffering, using the first two banks of the SDRAM, and everything appears fine when drawing simple objects to the screen.
However when drawing to the same part of the screen (all draws done to back buffer) more than once per screen refresh a visible glitch is observed, where part of the previous draws will be visible for a very short duration before disappearing. The size of the glitch appears to be directly proportional to the size of the area being drawn to.

I was able to replicate the issue on my DISCO-F746NG boards, except with the size of the glitch being far smaller, I’m assuming due to the same LTDC/SDRAM clock rates being used to draw on a far slower pixel clock. I’m using solid RG&B shapes for the replication, but it is just as, if not more obvious when drawing more complex objects, many of which are 4-5 individual props blended on top of each other directly into the back buffer.

Code published here for easy replication.

This is what it looks like if the code draws directly to the front buffer, and is also the exact same size and pattern as the glitch when double buffering (Just that the screen is predominantly blue with the coloured glitches visible). The color is also solid red (on a more expensive camera, the pink is just my phone not being ideal.

If anyone’s run into something similar and has an idea of what could be causing this I’d be glad to hear it. I’ve managed to make some improvements by enabling burst read/write SDRAM transfers (although this seems to create some “ghost” pixel glitches in addition to the (now) smaller block glitch) and really slowing down the LCD’s pixel clock. Similarly using a for loop to manually draw the pixels in creates a lot of noise in the glitch size, which was otherwise rock solid, which may be useful info. I’m suspecting the FMC/SDRAM being the primary culprit, but it’s by far the part of the STM32 I know least about, so I’m at a loss of what to try.

Regards,
Tom

9 posts - 5 participants