LPC4357 and LCD radiated emissions

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

LPC4357 and LCD radiated emissions

2,105 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by briching on Mon Jan 25 13:20:55 MST 2016
Our product has made it into the first round of EMC (Electro-Magnetic Compatability) and has failed radiated emissions testing.  We think we have proven it is the LCD display, as once we disconnect and power-down the display, everything passes.  On a long-shot, we wanted to see if there is anyone out there who is also having a hard time getting through EMC, and perhaps learn from what they have done to get their LCD in the system to pass.

Our setup involves a Newhaven 7" capacitive touch display running at 60p 16bpp(565), driven by an LPC4357 module that the LCD signals come out of a SODIMM connector similar to the EA OEM board, which the lower board adapts to a 40-pin FPC connector for the LCD.  Any individual LCD signal spanning both boards is not longer than 3 inches before the ribbon cable.  All signals are matched in length to within several millimeters.  However, the traces have not been routed as controlled impedance.  Note that the ribbon cable is longer than 3 inches itself.

Our pixel clock is running at 29.1 MHz, and therefore the data bus is running at 14.55 MHz.  We see this 14.55 MHz fundamental, as well as odd harmonics (3n, 5n, 7n, etc.) on a spectrum analyzer (at 1 meter from the DUT) when the LCD data bus is toggling all common-mode (i.e. 0xFFFF to 0x0000).  Differential mode (0xAAAA to 0x5555) drastically tames the emissions, as we suspect return paths are utilized between every other bit.  Common mode datapath toggling by far exhibits the worst emissions.  We can tame the common-mode emissions down with a ferrite core on the LCD ribbon, but we are still a ways away from passing.  Adding some copper foil tape on the LCD ribbon helps even more, but we are wondering if there is something fundamentally wrong with the LCD ribbon not having enough ground return paths.  The Newhaven ribbon pinout is quite horrible from an EMI perspective, as the entire 24-bit data bus is referenced to only 2 ground pins, one on either side of the 24-bit bus.  It sure would have been nice of them to throw in several more ground pins.

All the usual precautions in the design were taken, like a full metal enclosure, embracing ground, careful floorplanning, decoupling capacitors where they should be, etc.  We can also verify power and signal integrity of many of the signals in question with a scope.  Overshoots and undershoots on the LCD databus are pretty minimal, and power supply integrity fluctuates by several 10's of millivolts in the worst case around the vicinity of our LPC4357.

Our next design cycle will likely involve moving the LCD connector directly up to the board that has the LPC4357.  But I thought I'd at least ask around to see if anyone has experience with a 7" display being the tall pole in their compliance testing. 

Anyone out there have any ideas on how we can lower our radiated emissions using NXP and Newhaven displays?

Thanks,
Brad
Labels (1)
0 Kudos
6 Replies

1,157 Views
michele_sponchi
Contributor I

HI, I think I am late to the party, but maybe spreading the CPU clock could lower the LCD radiated emissions too.

We had a similar issue due to the RAM bus activity, and we lowered the EMI using a clock spreader chip for the CPU clock.

 

BR

Michele

0 Kudos

1,558 Views
rawsewage
Contributor III

briching,

I'm curious to know how your situation ended up, any chance you are still around to reply??  We are just beginning EMC/EMI testing with an LPC1850 and 7" LCD and I'm afraid we are running into similar issues as you did.  Thanks!

0 Kudos

1,558 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by briching on Tue Jan 26 14:26:55 MST 2016
Thanks Bavarian.  I checked my GPIO init code and it turns out we were already using the low drive strength and slower slew rates of those signals, as it looks like those registers default to those values unless you ask for more drive strength and faster slews.  I tried forcing it with the macros, but could not produce a measurable change. 

I'm only running 16 bits here, and I'm really wondering how anyone has been able to get a 24bpp 60p design to pass at all.  We may end up reducing the color depth even further, or start reducing our pixel clock to a point just above what we can't tolerate as far as flicker goes.  We are not trying to display video here, mostly static screens and menus, albeit with a decent resolution (800x480).  It is quite possible that we end up switching to a module with an embedded frame buffer and an interface we can more tightly control the data transport mechanism, for example only when we want to change screen content.  But the problem has always been pricing, availability, second sourcing etc, and we can't seem to find anything that would work with our price point of around $65 for an otherwise equivalent 7" (800x480) PCAP display.  Any suggestions on display alternatives are welcome.

Thanks again,
Brad

0 Kudos

1,558 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by bavarian on Tue Jan 26 02:12:05 MST 2016
You also could give it a try with configuring the I/Os of the LCD interface for slower behavior. There is a bit in the I/O setting (EHS) which influences the slew rate of the signals.

Regards,
Bavarian.
0 Kudos

1,558 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by briching on Mon Jan 25 17:41:09 MST 2016
Thanks for your reply.  We were thinking LVDS may solve our issues, but it presents several more, such as qualifying and evaluating an entirely new display.  It seems like switching to LVDS transmission does not get rid of the fact that at some point, there will need to be a short parallel ribbon cable near a large cutout in the chassis (the front of the display).  From what we can see, this is the case on many of the 7" displays out there.  They simply have stuck an LVDS board on the front end of an existing parallel display.  Ideally, we'd like an integrated display that accepts LVDS directly on the COG, but I haven't been able to find anything like this. 

I am ordering some LCL's off digikey tonight to prototype something by the end of the week.  From what I can see, cost doesn't seem to be too big of an issue yet.  I may end up adding $1 to $2 to my BOM.  The LCD refresh rate may also be more negotiable than I had thought, so if I can get the clock frequencies down, I should be able to slam dunk it with those filters.  Thanks so much for your help.

Brad
0 Kudos

1,558 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by wmues on Mon Jan 25 14:17:34 MST 2016
I know these problems well.

For a 7" Display, it is a good idea to move to LVDS transmission. There are parallel to (serial) LVDS converter chips available.

The biggest improvement is a foil cable with a ground shield area, covering all 40 wires. Of course this is a change in the display, because the ground shield has to be connected to the LCD.

To suppress harmonics, you might consider LCL-Filters (ferrite beads with 3 connections). Costly change on the board.
This will give you very large rise and fall times, but gives you several dBs.

a 30MHz Clock on a parallel LCD is on the edge of what is doable. Very heavy problem.

regards
Wolfgang
0 Kudos