Signal Integrity Problem

[TechnoGilles]

Hi,
My project is splitted into two (manufactured) PCBs linked together by a 8" long flat cable. Everything works fine between the two boards except for one signal that is buggy.

This signal is an IRQ (normally low and pulled down to ground through 5KΩ). It is generated by a Codec on my slave board and goes directly to the master board through the flat cable.

On the master board, it is received through a 74ACT245 transceiver, then it goes through a Xilinx CPLD (mostly to be ANDed with an "enable" register signal), then finally to the IRQ pin of a dsPIC30F microcontroller.

My problem is that even through the Codec is not asserting the IRQ signal, my microcontroller still processes interrupts once in a while, specifically when other communications take place between my two boards through the flat cable.

I suspect that the glitch occurs within the connection between the two boards but I'm laking the knowledge to figure it out or, for that matter, how to properly design and implement such a connection between two PCBs !!

Anyone can help ?
Thank you !
TechnoGilles

 

[MikeMl]

Use a ribbon cable with more wires, separate your signals so that they use every other wire in the ribbon; and then ground the ones in-between the signals. This will stop capacatively-coupled crosstalk from one signal line to the next.

 

[TechnoGilles]

Use a ribbon cable with more wires

Arghh!! I was afraid of such an answer !!!

But I can't really afford to modify my connector layout. It would basically mean re-buy the PCBs and the parts and redo it all !!

Do you think there is another way to clean the faulty signal ?

I tried pulling it down to ground on both sides of the connection with 5k resistors. This makes a total pull down of 2.5k. The signal is still buggy. Do you think crosstalk can be strong enough to bring up that signal to trigger the interrupt ?

 

[mneary]

Without some serious circuit changes your best bet is a digital filter in the CPLD. Clock the IRQ in and check it on several subsequent clock cycles. Verify that it is identical for at least a few microseconds before passing any changed state on to the dsp.

 

[TechnoGilles]

Digital filter in the CPLD would have been nice, thanks ! But my CPLD is totally passive (not clocked) and I have no pin left to feed one in.

Looks like I'm up for the big changes then ! Besides Mike's suggestion of interleaving signals in the flag cable with grounds, it there anything else I should pay attention to while refactoring the connection ?

 

[mneary]

Think of any event that you can use to run a noise filter. How about the communication clock? The comms data itself? Is there an input from the CPLD that is rarely used (e.g. start up) that could be turned around during operation? How about the EEPROM lines? Does the dspic see them?

Can you reduce the cost of false interrupts by validating them quickly and returning if they are false? Is the CODEC interrupt periodic or random? Can you safely ignore it some of the time?

 

[TechnoGilles]

The signal from my CODEC is a level-sensitive IRQ that remains HI as long as the CODEC's playback FIFO is not full. Under steady-state condition, it runs at 48kHz. I use the rising edge of the signal to trigger my dsPIC interrupt. After that, I read the actual signal value to fill up the FIFO with samples. If I happen to misread the signal, I will end up writing a value to the CODEC at the wrong time screwing up my playback.

More over, my main program loop wakes up on every interrupt to figure out what happened and decide what to do next. This times adds up to the time it takes to context switch to the ISR itself so every "false" interrupt becomes very costly !

As for CPLD signal I could use as a clock, I can't see any. They are all too "random" or too low frequency. I'll try to implement one internally to my CPLD (by putting a few inverters in loop, the good old way !) but I doubt Xilinx tool will let me do that...

 

[TechnoGilles]

Ok. I had a few floating wires in my flat cable (which is 50-wire large), and also a couple of signals I could get rid of. I grounded them on both sides of the connection and it significantly improved the situation.

Is there any kind of "sheilding" I could add to (or around !) the flat cable to further increase the reliability ?