PXP example for lcdif handshake on 1060 EVK has artifacts

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

PXP example for lcdif handshake on 1060 EVK has artifacts

1,669 Views
nxp16
Contributor III

Hi,

I'm seeing some weird artifacts on the edges of the blue and red blocks in the lcdif handshake example for PXP in the 2.9.1 sdk for the 1060 EVK.  If I run the blend example I don't see them.  Does anyone else see this problem?  It makes me doubt whether I'll be able to use this handshake for efficient graphics if this is what's going to happen.  I also tried this example with another display (an 800x480 display from adafruit).  That has worse problems; the right edges of the blocks are all checker chunky.  The blend example works fine.  It's just this lcdif handshake one that is suspect.  Is it possible that the porch, etc, settings in the example app are off?

Thanks!

0 Kudos
7 Replies

1,629 Views
nxp16
Contributor III

Yes, the display that came with my 1060evk looks just like that.  You can probably see on your own screen that some of the edges have a couple pixel wide blur.  I can see it in your video.  I have set my pixel clock, resolution, and porch etc parameters according to the datasheet for my display.  Every other example works flawlessly (lvgl demo, embedded wizard demos, emwin demos, pxp blend, pxp_queue, etc.  Just the LCDIF handshake one has problems.

0 Kudos

1,595 Views
gusarambula
NXP TechSupport
NXP TechSupport

Hello nxp16,

The blur you mention is noticeable on the video, but not on the real-life demo. It would probably not be classified as an artifact, unlike on the larger displays where there is definitely errors happening.

Given that the other examples work correctly, it could be that the problem is related to the LDCIF Handshake in particular (which the example is testing). It is possible under some scenarios (high LCDIF output rates with high memory latency) that the PXP may not be able to keep up with the LCDIF. The Reference Manual has some additional details but then this happens the PXP will abort processing in the current row and proceed to the following row.

This behavior would create artifacts on the video display, and I suspect may be what’s happening in the larger display.

 Regards,
Gustavo

0 Kudos

1,589 Views
nxp16
Contributor III

That's what I was thinking too but was hoping it wasn't the case.  I'm seriously surprised that PXP could be so slow it couldn't even keep up with a 565 640x480 display.

0 Kudos

1,638 Views
nxp16
Contributor III

Video of the 800x480 LCD.  https://photos.app.goo.gl/LAWT3cks21Cqc8gr6

0 Kudos

1,633 Views
gusarambula
NXP TechSupport
NXP TechSupport

Hello nxp16,

Thank you for sharing the video of these artifacts.

For reference, the demo should run as in the attached video.

If you are using a different display than the default RK043FN02H-CT, you may need to change the resolution settings and the pixel clock accordingly. It could be that only part of the screen is showing due to these settings. Would you please confirm if you have changed them on the example before running? Please let us know if it improves this symptoms.

Regards,
Gustavo

0 Kudos

1,638 Views
nxp16
Contributor III

Hi,

I tried to take a video but it just comes out blurry.  I can't take a picture because if I pause the program in the debugger the screen goes blank and it never starts drawing again.  I see this problem no matter how I run it, whether immediately starting it after the debugger finishes loading it, or power off/on without the debugger.  I will try to take a video/picture if I can tomorrow.  The artefacts aren't so bad on the default display that comes with the evk (just a little blurry edge on the side that's moving; it almost looks like the edge is rounded or shadowed).  But on any bigger display the artefacts are horrible.

0 Kudos

1,640 Views
gusarambula
NXP TechSupport
NXP TechSupport

Hello nxp16,

I tried reproducing these symptoms with the i.MXRT1064EVK (2.9.1 SDK, lcdif handshake example) to no avail. The i.MXRT1064 is based on the i.MXRT1060 with an added ON-Chip Flash, so it should be reproducible in this board.

Would you please provide more details on how to reproduce this error? Does it appear consistently after reset or with a certain frequency? Are you running the example continuously (I’m asking because the readme warns on possible errors if the example is not run continuously, so you may find it not working correctly if the system is halted while running)?

Would it be possible to have a picture of these artifacts?

Regards,
Gustavo

0 Kudos