LPC1820 and I2C

[lpcware]

Content originally posted in LPCWare by vdelabouere on Mon Sep 15 07:40:57 MST 2014
Hi all,
I'm using a Wolfson DAC (WM8523) which is connected to the I2C0 bus of the LPC1820.

The I2C communication is not very robust. Many times the Wolfson codec doesn't acknowledge the slave address. The data and clock signals look clean on the scope. I improved I2C communication by changing the pull ups from 10K to 1K but still not 100% reliable !

We are using this DAC for a long time but it is the first time I'm using a combination of LPC+WM8523

Is there any known I2C issues between the LPC1820 and this wolfson DAC ?
Thanks for your help.

Vince

[lpcware]

Content originally posted in LPCWare by Microknight on Tue Jun 14 08:14:13 MST 2016
Hi,

A quick update to anyone interested.
I couldn't find anything obvious (WRT noise) on the clock line. So I tried vmues workaround and it "solved" the issue.

By using the Bus Collision detection to detect the stuck data line. I then switched the I2C module off and manually put out clock pulses until the data line returns to high. I then switched the I2C module back on and retried the last transaction. Works a treat. I do only have a single master on the bus though, which I suspect makes it easier. On a multi-master bus it would be more complicated, but fortunately I don't have to go there :-)

Thanks
Graeme

[lpcware]

Content originally posted in LPCWare by Microknight on Fri Jun 10 04:23:27 MST 2016
Hi Vince,

I know you posted this a long time ago, but I came across this post in a search and wondered it you ever got to the bottom of your issue.

I'm also using this DAC. I have 4 of them on the same I2C, plus there are 5 processors spread over 3 interconnected boards. Only one processor is the bus master. The DACs are I only addressed at startup to transfer config. And all that seems OK every time.
I then poll and transfer data around the various other processors on regular basis. Very occasionally the Data line of (any) one of the DACs spontaneously gets pulled low and holds the bus to ransom. If I disconnect the DACs from the bus then the master springs back to life. I'm guessing it could be a similar thing if one of the DACs is responding to a spurious clock. I use 2K4 pull-ups and have no issues with any of the other devices on the bus.

Anyway was just wondering :-)

Regards
Graeme

[lpcware]

Content originally posted in LPCWare by wmues on Mon Sep 15 12:51:01 MST 2014
There a 2 issues with I2C and these "modern" DACs....

1) These DACs are missing a spike filter. Short spikes on the lines (if the line is HIGH and has a HIGH impedance) will be received as a valid clock signal.

2) For the ACK, the codec will drive the line. If the codec output impedance is low, the dV/dt on the I2C data line is high. If you have routed the CLK and the DATA line in parallel, the ACK signal on the data line will produce a spike on the CLOCK line -> see 1)

What to do?
A) use a PUSH/PULL driver for the CLOCK line. If this is not possible with the LPC, add a buffer (tiny logiv, LVC) to the CLOCK line, so that the lock line has a low impedance.

B) Separate the CLOCK and the DATA line in your layout.

C) Detect the missing ACK per Software and implement a I2C reset:
- switch the I2C pins to GPIO
- Set the DATA line to Input
- Toggle the CLOCK line with 400KHz
- Repeat toggling the clock line until there a N clock with DATA = 1
- N = longest number of bits in the codec command sequence.
- Send a STOP
- reset the I2C controller in the LPC and switch the Pins back to I2C mode.

Been there, done that.
regards
Wolfgang