Color patterns on LCD disturb ETH or USB

Discussion around products based on ARM Cortex-A5 core.

Moderator: nferre

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.

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 ... 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
Location: USA
Posts: 1508
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


Return to “SAMA5D Cortex-A5 MPU”

Who is online

Users browsing this forum: No registered users and 1 guest