Problem with pixels "bleeding" into where they shouldn't be.

[psilvaggio]

I’m having an issue with pixels “bleeding�? into places where they shouldn’t be. See the photos below.

In screenshot1 (with the colorful shapes), on the lefthand side of the red circle and the triangle on the right, inside the shape the green background seems to be bleeding into the shape. On the righthand side of the shapes, the shape color seems to be bleeding into the background. One thing that’s notable is that the perfectly horizontal side of the line at the top and perfectly vertical sides of the left triangle don’t seem to have a problem. Maybe something to do with alpha on the diagonal edges of the shapes?

In screenshot2 (white background with a few black lines), the pixels of the leftmost line seems to be bleeding onto the other edge of the screen.

This is a custom PC board connecting to an ARGB 24 bit TFT LCD, utilizing TouchGFX v4.20. Originally we used the STM32F429IIT6 processor, which worked fine without this issue, and is in production. We had to redesign the board to use the STM32H743BIT6 processor, and which is when we discovered this “bleeding�? problem. We are using the same external RAM as the F4 version (for frame buffer), and the vast majority of the other components on the board are the same.

For experimentation we have a project built using the STEMWIN graphics set, that we loaded onto the very same H7 board and with no bleeding problem, so this leads me to believe it’s likely not a hardware issue. I have to believe it’s some setting/configuration that is wrong. I did compare the settings of the F4 and H7 projects and I believe I have everything the same.

I’m able to write/read the external memory (as explained in https://support.touchgfx.com/4.20/docs/development/board-bring-up/how-to/04-enable-external-ram), and the frame buffer is obviously working on some level since we’re able to see something resembling the intended graphics on the screen.

What should I be looking at to fix this issue? Is this a FMC/RAM config problem (timing?), or LTDC (front/back porch?), or something else? I’ve included screenshots of the settings I have in the STM32Cube project. Thank you.

[MM..1]

If i good understand TouchGFX dont require or use ARGB formats for framebuffer. Set it seems as waste memory.

As second F4 vs H7 is big different in clock and speed. You cant say design is same.

And testing with canvas objects (code generated) isnt perfect choice. Is your canvas buffer setting for screen same ?

[MTora.1]

Hi dears

I have the same problem too. it becomes worse when I animate images.

I checked Ram several times. I used Freertos.

please help me. I marked some wrong points.

did you face the same problem?

 strange that sometimes it fix and after a while, it broke like the attached image.

[MTora.1]

what's canvas?

[Tesla DeLorean]

Check external memory cycles/timing consistency

Perhaps caching / write-thru creating some tight timing, or back-to-back operation.

[MTora.1]

Dear DeLorean

I checked EX RAM, Except I have mistakes in some parts.

Is it possible to be the wrong adjustment in FreeRTOR?

something confused me, It works after several programming.

something except Board must be having a problem.

I use another system to program and it happened randomly too.

I use MT48LC16M16A2P-6A RAM.

[psilvaggio]

Since there's activity on this post, I'll say that my original issue was fixed by tweaking the external SDRAM timings.

[Tesla DeLorean]

What speed is clocking? This will dictate the length in cycles, as these will need to meet the min/max TIME specified in the SDRAM specification / data sheet.

Perhaps add a little additional margin where is is tight.

On H7 I might look at SPEEDR on pins, and IO Compensation cell.

I'm assuming the triangle and circle are drawing primitives, not bitmaps copied from external memory, but the frame buffer is in SDRAM

[MTora.1]

:sad_but_relieved_face: I program the last project. It works properly.

then I return to the new project, It works properly.

I'm sure it work for a while.