Tearing on LCD when accesing USB

[lpcware]

Content originally posted in LPCWare by larsjep on Mon Mar 24 05:47:21 MST 2014
Hi,

I'm having a problem with tearing on the LCD display.
The tearing occurs when I transfer data to and from a USB stick.
(On USB0 High-speed mode)

The display resolution is 800x480 16bit
The memory is 2x16MB (32bits bus) SDRAM running at 102Mhz.
The CPU core is running at 204Mhz.

It seems like the USB DMA is disturbing the LCD DMA.

I have tried to lower the DMA burst size of the USB controller with register BURSTSIZE, but I can't change these values. It keep going back to 0x1010 which is default.

Is it possible to lower the DMA priority of the USB controller somehow ?
Any ideas on how to solve this ?


Best regards
  Lars

[lpcware]

Content originally posted in LPCWare by mc on Fri Oct 30 14:43:17 MST 2015
Hi briching,
We are updating UM and will be available in early November (2015).

[lpcware]

Content originally posted in LPCWare by briching on Tue Oct 13 09:26:51 MST 2015
This is the only google search result I could find that is relevant to the keywords SBUSCFG and NXP.  I don't think the documentation has been completed for this register yet.

[lpcware]

Content originally posted in LPCWare by mysepp on Fri Oct 09 02:15:39 MST 2015
Perhaps overseen, but it is also not yet in user manual? Or have you found a description?

[lpcware]

Content originally posted in LPCWare by briching on Thu Sep 24 20:13:39 MST 2015
I can confirm this fix as well.  We have an 800 x 480 TFT display with 16bpp (565) 60fps driven by an LPC4357.  For the first time today we noticed LCD fifo underflow interrupts being generated whenever the USB host stack (lpcusblib) accessed the attached mass storage thumb drive.  The distortion pattern was different than what is described on Segger's site in terms of a "page tear".  It was more like the image was being corrupted and shifted around a bit (as would likely be exhibited as the data stream is starved when the LCD controller's DMA fifo underflows.)

Many thanks for publishing this fix.  I'm sure I would have been scratching my head for days or weeks over this.  I happened to get lucky in a google search finding this, but if a link to this page isn't already in the lpcopen FAQ's, should it be?

Thanks,
Brad

[lpcware]

Content originally posted in LPCWare by larsjep on Thu Apr 24 05:34:59 MST 2014
Hi,

I just want to mention that I solved the problem with help from NXP support.

I got this from the support:

---

Quote:
Can you try after writing a value to an undocumented register:
*((volatile uint32_t *)0x40006090) = 7;
(Another possible value is 3)

---

---

Quote:
It controls the way in which the USB bus master tells a bus slave (here: the memory controller) how it wants to perform a burst data transfer.
It has recently been discovered that the default setting is not always optimal.
The proposed register is called "SBUSCFG", and will be documented in a new version of the manual.
No bad side effects are expected, and the non-zero setting will actually be recommended for all applications.

---

This seems to solve the problem  8-)

Good luck.

[lpcware]

Content originally posted in LPCWare by mdittrich on Mon Mar 24 09:47:26 MST 2014
OK, sorry I always interpreted "tearing" as half of the new "screen" being displayed while half of the old is still also being displayed.  Which, in any case, is obviously not your problem.  Besides dropping to 8bit palettized mode, I have no suggestions...

but hope you reach/share a solution, because it sounds like I will be in your situation when we implement USB (nearly identical hardware setup, but we are already using 8bit palettized mode).

Good luck!

MD

[lpcware]

Content originally posted in LPCWare by larsjep on Mon Mar 24 09:08:08 MST 2014

---

Quote: mdittrich
I am assuming you are using the onchip LCD controller...  Have you experimented with double buffering the LCD (by swapping buffers with LPC_LCD->UPBASE from within the LCD interrupt when the LNBUMIS bit is set)?

---

Yes, I allready do this, but the problem occurs also when I'm not updating the buffer.

---

Quote: mdittrich

Are you getting LCD FIFO underflow or LCD AHB master bus errors when running USB?  I sometimes throw a

---

Yes, I get a LCD FIFI underflow when the tearing occurs.I'm not sure how test for AHB master bus error. ?

---

Quote: mdittrich

    
    if(CoreDebug->DHCSR & CoreDebug_DHCSR_C_DEBUGEN_Msk) {
        __asm volatile ("bkpt");
    }

for these type of error interrupt sources, so my debugger stops when they happen without having to specifically set a breakpoint.

---

Great idea, I will use that in the future

---

Quote: mdittrich

I have no experience with the USB peripheral (yet).

MD

---

[lpcware]

Content originally posted in LPCWare by mdittrich on Mon Mar 24 08:40:24 MST 2014
I am assuming you are using the onchip LCD controller...  Have you experimented with double buffering the LCD (by swapping buffers with LPC_LCD->UPBASE from within the LCD interrupt when the LNBUMIS bit is set)?

Are you getting LCD FIFO underflow or LCD AHB master bus errors when running USB?  I sometimes throw a

    
    if(CoreDebug->DHCSR & CoreDebug_DHCSR_C_DEBUGEN_Msk) {
        __asm volatile ("bkpt");
    }

for these type of error interrupt sources, so my debugger stops when they happen without having to specifically set a breakpoint.

I have no experience with the USB peripheral (yet).

MD