[SOLVED] LPC1788 LCD display noise issue

[lpcware]

Content originally posted in LPCWare by sgiorgetti on Wed Apr 09 23:59:13 MST 2014
Hello everybody,
we're facing an annoying issue on 30% of production boards and as of today I wasn't able to find any firmware solution to this, even following every post found in this board about LCD and SDRAM initialization procedures.

On affected boards, the LCD shows a lot of pixel noise, as shown in following photo:
[img]http://www.lpcware.com/system/files/TFT%20Noise%20-%20details.jpg[/img]

I am not yet able to determine if this is a LCD or SDRAM peripheral issue, anyway I've found that applying a mechanical pressure on chip, the display changes and it shows the secondary buffer content.
[img]http://www.lpcware.com/system/files/TFT%20Noise%20-%20mechanic%20action.jpg[/img]

In previous picture you can see that the active buffer (flags page) disappears and the secondary buffer (black background with some texts) reappears.
This is exactly the last content of the active buffer, as the previous shown page is
[img]http://www.lpcware.com/system/files/TFT%20Noise%20-%20previuos%20active%20buffer.jpg[/img]

I'm using a custom middleware graphic library, but I don't think that it's a library problem.
The LCD video RAM is managed as a simple double buffer that's stored into two SDRAM sections:

#define C_GLCD_H_SIZE           480
#define C_GLCD_V_SIZE           272
#defineLCD_BPP2/**< LCD byte-per-pixel */


/** Video memory base address */
#define GLCD_BUFFER_BASE0xA0000000/* Uses external SDRAM on DYCS0 */
/** Single buffer dimension [byte] */
#define GLCD_BUFFER_SIZE(C_GLCD_H_SIZE*C_GLCD_V_SIZE*LCD_BPP)

Buffer #1 @ GLCD_BUFFER_BASE
Buffer #1 @ GLCD_BUFFER_BASE+GLCD_BUFFER_SIZE

I'm investigating about:
[list]
  [*]hardware issues (fact: the changes caused by pressure are strange)
[*] LPC peripheral initialization issues (fact: playing with both LCD and SDRAM parameters I can either totally block the application or have no effect at all)
[*] ???
[/list]

I'd really appreciate any possible hint about this problem.
Thank you very much

[lpcware]

Content originally posted in LPCWare by sgiorgetti on Tue May 20 07:32:30 MST 2014
SOLVED!

The problem wasn't related to LCD controller but to external SDRAM timings.
In particular I've found that settings the EMCDLYCTL register to 0x00080808 fixed the issue.

Thank you all for the assistance!

[lpcware]

Content originally posted in LPCWare by sgiorgetti on Mon Apr 14 02:39:04 MST 2014
Hello everybody,
I'd want to update you about this fact that emerged during my testing.

I've got two identical boards:
[list]
[*]one perfectly working - we call them A-board
[*]one with the described defect -  we call them B-board
[/list]
I've checked LCD and SDRAM signals, one by one, comparing the good one with the bad one: no differences in signal amplitudes and shapes.
Nothing.
Then I decided to perform another test: if I switch the LP1788 between these boards, the issue switches too!!!

Now I've got (simply switching the LPC1788, I repeat) the following situation:
[list]
[*]the B-board is perfectly working, even the mechanical action described doesn't lead to any image change on display
[*]the A-board has the same LCD noise issue previously seen, mechanical action too.
[/list]

May it be some internal MCU issue?

[lpcware]

Content originally posted in LPCWare by sgiorgetti on Thu Apr 10 23:50:43 MST 2014

---

Quote: nxpsupport
The first image looks like it has both buffers being displayed, indicating a setup/configuration problem.  
Regarding the 'noise', on the 3rd image it looks like a timing issue - some lines are displayed in the wrong position, which could be caused by another bus master (especially a DMA operation, or even a LDM/STM operation) interfering with the LCD controller fetching framebuffer data.

---

I'm still investigating about timing issues too, as it seems to me that there are a lot of pixel "misplacements".
But any action on peripheral setups leads to no difference at all or to
[list]
  [*]usual bad timings display when going to far with LCD timing settings
  [*]complete crash of the system at first SDRAM access when hacking EMC parameters
[/list]
Regarding DMA conflicts, the LCD/SDRAM bus is the only DMA channel used in this particular application.

Thank you

[lpcware]

Content originally posted in LPCWare by sgiorgetti on Thu Apr 10 23:20:56 MST 2014

---

Quote: usb10185
Hi,
Seems to be a timing or hardware issue or combo of both. Hard to tell. The buffer behavior seems to point to SDRAM connection.
What is the core and sdram clock values?

Some things to try:
Slow down the LCD pixel clock
Check the LCD FIFO Underflow flag - FUFRIS - is it set?

Good luck!

---

Thank you,
I've already slowed down the LCD clock with no positive results.
Honestly, I hadn't check yet that FUFRIS flag: I'm doing it now.

[lpcware]

Content originally posted in LPCWare by sgiorgetti on Thu Apr 10 23:19:19 MST 2014
Thank you Rocketdawg.
BTW the display variations are present even if I bend the PCB as you told me to or.
More, even deforming the PCB by a mechanical insulated tool leads to those results.

[lpcware]

Content originally posted in LPCWare by nxpsupport on Thu Apr 10 14:26:00 MST 2014
The first image looks like it has both buffers being displayed, indicating a setup/configuration problem.  
Regarding the 'noise', on the 3rd image it looks like a timing issue - some lines are displayed in the wrong position, which could be caused by another bus master (especially a DMA operation, or even a LDM/STM operation) interfering with the LCD controller fetching framebuffer data.  Look at the bandwidth required for the refresh settings/panel size/color depth vs the memory bandwidth (wait states, taking DRAM refresh cycles into account).  What is the CPU doing?  Does this happen if the CPU is executing from cache or internal RAM to stay off the bus, and no other bus masters? 

Given that is it only a fraction of systems, check connections too.  Noise on control & LCD clock lines/cross talk, bad solder connections, and flaky LCD connectors can also cause these issues.

[lpcware]

Content originally posted in LPCWare by usb10185 on Thu Apr 10 11:31:42 MST 2014
Hi,
Seems to be a timing or hardware issue or combo of both. Hard to tell. The buffer behavior seems to point to SDRAM connection.
What is the core and sdram clock values?

Some things to try:
Slow down the LCD pixel clock
Check the LCD FIFO Underflow flag - FUFRIS - is it set?

Good luck!

[lpcware]

Content originally posted in LPCWare by rocketdawg on Thu Apr 10 08:11:32 MST 2014
No idea, but here is an observation.

By pressing on the chip, I notice your fingers on the back side of the board.
I assume there are traces, via, maybe even passive components on the back side.
how many board layers?
your fingers add resistance (albeit very high) and some capacitance.
what traces or components are on the back side?
via under the chip?

assume it is mechanical
try flexing the board from the ends, twisting it, ...  perhaps it is a via problem or a solder problem.

not mechanical
timing changes due to your fingers?
check that power supply, causes more problems.

what is on the end of that ribbon cable?  Something noisy?