Color patterns on LCD disturb ETH or USB

Discussion around products based on ARM Cortex-A5 core.

Moderator: nferre

johanc
Posts: 1
Joined: Mon Apr 24, 2017 9:06 am

Color patterns on LCD disturb ETH or USB

Mon Apr 24, 2017 10:43 am

Hi !

I encountered very weird issue (also easy repeatable on demo SAMA5D3x-MB board, ATSAMA5D31 SoC):

Writing some patterns in "video" memory (and having LCDC enabled) causes packet errors (CRC, bad signals) on USB on our custom board, but when tried on demo board, they cause packet stalls?? on ethernet.

These errors do not occur when pixels only have 1 bit per RGB component changing or all pixels are of the same color.

e.g.:
BGR = 0x808080, 0x020202, ... pattern does not produce errors, neither does 0xFFFFFF, 0xFFFFFF, ...
however BGR = 0xFFFFFF, 0x000000, ... produces errors

I tried different kernel versions (mainline 4.4, mainline 4.9, Linux4SAM 3.10, Linux4SAM 3.18, Linux4SAM 4.4) and also "reference" image from http://www.at91.com/linux4sam/bin/view/ ... ekMainPage to make sure it is not our customized firmware or board that is a problem.

Disconnecting LCD from board does not help either (those signals are all just outputs, but still). Severely reducing dotclock frequency (to unusable levels) does however reduce number of errors (but not eliminate??). Using dri/drm instead of fbdev does not help.

Anyone has any idea what might be the problem as the whole thing just doesn't make any sense ? DMA arbitration problem in SoC ? Linux kernel problem ? Something else ?

Can anyone confirm and check on their board with this simple quick&dirty test:

1.connect to your board over ethernet using ssh and do continuous listings:

Code: Select all

while true; do dmesg; done
2.have another connection to board (serial or network) and turn on lcdc (if using fbdev emulation over dri, make sure you enable it (like cat /sys/class/graphics/fb0/modes > /sys/class/graphics/fb0/mode)
Close any application that might be writing to fb.
3.fill video memory with random pixels

Code: Select all

 cat /dev/urandom > /dev/fb0 
4.observe listings on ssh connection -> stalling
5.fill video memory with black pixels

Code: Select all

 cat /dev/zero > /dev/fb0 
6.observe listings on ssh connection: smooth again

Currently we use quick and dirty patch in user application to only use colors that have only one bit enabled per RGB component to avoid severe problems on field, but that heavily restricts application (reduces number of colors from 2^18 to 8^3).

Thanks to anyone spending time to at least try the test (please report findings: if the communication does not get stuck, which kernel are you using?)

Best regards
blue_z
Location: USA
Posts: 1560
Joined: Thu Apr 19, 2007 10:15 pm

Re: Color patterns on LCD disturb ETH or USB

Tue Apr 25, 2017 2:38 am

Cannot replicate any problem on a SAMA5D36-EK, running
Linux buildroot 3.10.60+at91 or
Linux sama5d3xek 4.1.0-linux4sam_5.2-00025-g1028912

Regards
justas
Posts: 4
Joined: Thu Dec 03, 2015 11:02 am

Re: Color patterns on LCD disturb ETH or USB

Tue Dec 05, 2017 4:19 pm

Hi,

I have very similar problem.
Some info: custom board based on sama5d3xek, linux-at91 4.4. Runs 1024x600 lcd and QT5 app using linuxfb(also tried drm). 166MHz system clock, 41MHz pixel clock and DE mode.

In my case the LCD starts to distort and finally enters blanking mode (I can reset it by writing 0 to /sys/class/graphics/fb0/blank). By distortion I mean jumping picture, like timing issue. The easiest way to reproduce this is to copy files from SD card using mass storage gadget and attach device to USB master (wifi dongle is the worst). Slight distortion can be seen under different bus loads. Loading CPU makes no difference. When LCD failing other operations are not effected.

Changing pixel or system clock makes situation worse. Trying to cp file from SD makes LCD go to blank instantly. Our Initial thought was the hw noise problem (we use parallel to LVDS converter) but how the frame buffer device switches to blanking without any feedback? Tried 4.9 kernel, looks a bit better, but distortion still visible.

My best guess this some kind of DMA or video memory problem. Maybe someone has any suggestion what I could try next to debug this problem? Thank you in advance.
justas
Posts: 4
Joined: Thu Dec 03, 2015 11:02 am

Re: Color patterns on LCD disturb ETH or USB

Fri Dec 08, 2017 1:59 pm

Investigated some more. Lowering pixel clock to eye visible levels solves this problems. Also with higher lines count USB starts to fail. Seems like memory isn't fast enough and LCDC don't have the highest priority.

Return to “SAMA5D Cortex-A5 MPU”

Who is online

Users browsing this forum: No registered users and 1 guest