WM8731 Audio Codec, I2C weirdness

[oweno]

I've been trying to get the WM8731 audio code working with the Compute Module 3.

This part works fine with the Pi 3B, but is unreliable with the CM3. Using the CMIO board or our custom board, the problems seem to be I2C related. The WM8731 is configured over I2C, and on the CM3 setup many of the transmissions ended up being NACK and the WM8731 is not correctly configured. Usually this leads to audio silence, but can also cause horrible noises when the registers are not set properly.

For example, a correct initialization might look like this on the Pi 3:

Code: Select all

 Decoded Protocol Result
Setup Write to [0x34] + ACK
0x0A + ACK
0x09 + ACK
Setup Write to [0x34] + ACK
0x0C + ACK
0x46 + ACK
Setup Write to [0x34] + ACK
0x10 + ACK
0x23 + ACK
Setup Write to [0x34] + ACK
0x0E + ACK
0x4E + ACK
Setup Write to [0x34] + ACK
0x0C + ACK
0x42 + ACK
Setup Write to [0x34] + ACK
0x10 + ACK
0x23 + ACK
Setup Write to [0x34] + ACK
0x0E + ACK
0x4E + ACK
Setup Write to [0x34] + ACK
0x0A + ACK
0x01 + ACK
Setup Write to [0x34] + ACK
0x0A + ACK
0x01 + ACK

Then on the CM3 setup:

Code: Select all

 Decoded Protocol Result
Setup Write to [0x34] + ACK
0x0A + ACK
0x09 + ACK
Setup Write to [0x34] + ACK
0x0C + ACK
0x46 + ACK
Setup Write to [0x34] + ACK
0x10 + NAK
Setup Write to [0x34] + NAK
Setup Write to [0x34] + ACK
0x0C + ACK
0x42 + ACK
Setup Write to [0x34] + ACK
0x10 + NAK
Setup Write to [0x34] + ACK
0x0E + ACK
0x4A + NAK
Setup Write to [0x34] + ACK
0x0A + ACK
0x01 + ACK
Setup Write to [0x34] + ACK
0x08 + NAK

I've added pull up resistors to the I2C lines in the CM3 setup, and tried different values, and the signals look clean on the scope. But still getting tons of NACKs. Makes me think something else is going on the with the I2C pins or something not configured properly... any ideas what could be going wrong?

[6by9]

Which GPIOs are you using, and which i2c interface?
Certainly if you have managed to map SDAx or SCLx to multiple GPIOs then you will get issues with NAKs on everything, the same as if SDAx was constantly pulled to ground. IIRC internally the two GPIOs will be logical or'ed, therefore the pull up resistors on the other set of GPIOs result in an output high. i2cdetect is likely to report all addresses as detected.
Post the output of "raspi-gpio get".

[oweno]

Thanks. I was hoping it was something config related, but I've been over the GPIO setup many times, unless there is something I am missing.

Using i2c1 on pins 2,3

Here is "raspi-giop get":

Code: Select all

BANK0 (GPIO 0 to 27):
GPIO 0: level=1 fsel=0 func=INPUT
GPIO 1: level=1 fsel=0 func=INPUT
GPIO 2: level=1 fsel=4 alt=0 func=SDA1
GPIO 3: level=1 fsel=4 alt=0 func=SCL1
GPIO 4: level=1 fsel=0 func=INPUT
GPIO 5: level=1 fsel=0 func=INPUT
GPIO 6: level=1 fsel=0 func=INPUT
GPIO 7: level=1 fsel=0 func=INPUT
GPIO 8: level=1 fsel=0 func=INPUT
GPIO 9: level=0 fsel=0 func=INPUT
GPIO 10: level=0 fsel=0 func=INPUT
GPIO 11: level=0 fsel=0 func=INPUT
GPIO 12: level=0 fsel=0 func=INPUT
GPIO 13: level=0 fsel=0 func=INPUT
GPIO 14: level=0 fsel=0 func=INPUT
GPIO 15: level=0 fsel=0 func=INPUT
GPIO 16: level=0 fsel=0 func=INPUT
GPIO 17: level=0 fsel=0 func=INPUT
GPIO 18: level=1 fsel=4 alt=0 func=PCM_CLK
GPIO 19: level=0 fsel=4 alt=0 func=PCM_FS
GPIO 20: level=0 fsel=4 alt=0 func=PCM_DIN
GPIO 21: level=0 fsel=4 alt=0 func=PCM_DOUT
GPIO 22: level=0 fsel=0 func=INPUT
GPIO 23: level=0 fsel=0 func=INPUT
GPIO 24: level=0 fsel=0 func=INPUT
GPIO 25: level=0 fsel=0 func=INPUT
GPIO 26: level=0 fsel=0 func=INPUT
GPIO 27: level=0 fsel=0 func=INPUT
BANK1 (GPIO 28 to 45):
GPIO 28: level=0 fsel=0 func=INPUT
GPIO 29: level=0 fsel=0 func=INPUT
GPIO 30: level=0 fsel=0 func=INPUT
GPIO 31: level=0 fsel=0 func=INPUT
GPIO 32: level=0 fsel=0 func=INPUT
GPIO 33: level=0 fsel=0 func=INPUT
GPIO 34: level=1 fsel=0 func=INPUT
GPIO 35: level=1 fsel=0 func=INPUT
GPIO 36: level=1 fsel=0 func=INPUT
GPIO 37: level=0 fsel=0 func=INPUT
GPIO 38: level=0 fsel=0 func=INPUT
GPIO 39: level=0 fsel=0 func=INPUT
GPIO 40: level=0 fsel=0 func=INPUT
GPIO 41: level=0 fsel=0 func=INPUT
GPIO 42: level=0 fsel=0 func=INPUT
GPIO 43: level=0 fsel=0 func=INPUT
GPIO 44: level=0 fsel=0 func=INPUT
GPIO 45: level=0 fsel=0 func=INPUT
BANK2 (GPIO 46 to 53):
GPIO 46: level=1 fsel=0 func=INPUT
GPIO 47: level=1 fsel=1 func=OUTPUT
GPIO 48: level=0 fsel=4 alt=0 func=SD0_CLK
GPIO 49: level=1 fsel=4 alt=0 func=SD0_CMD
GPIO 50: level=1 fsel=4 alt=0 func=SD0_DAT0
GPIO 51: level=1 fsel=4 alt=0 func=SD0_DAT1
GPIO 52: level=1 fsel=4 alt=0 func=SD0_DAT2
GPIO 53: level=1 fsel=4 alt=0 func=SD0_DAT3

Does this show the whole picture? or could there still be something funny about the pins?

Also, I'm starting to think it is something electrical.. I didn't notice at first, but lowering the pull-up resistor value seems to improve the situation. Originally it was 4.7K, and things get better replacing with 1.2K. Moving down to 750 Ohm, the NACKs almost disappear completely (but still happen about 1% of bytes sent). so I don't know seems crazy to me....

[6by9]

Software config all looks OK, so I would suspect something in your wiring.
The standard pull ups on the 3B are 1k5. NAKs are the device not pulling the line low for the ACK, or not being able to. More likely that the actual comms has failed so it doesn't recognise the transaction. High capacitance on the lines resulting in indistinct transitions?

Nothing else springs to mind. Software-wise both platforms should be the same (assuming similar kernel versions).

[oweno]

Yeah, definitely some electrical issues. Lowering pull-ups help, but something going on with our boards I think.

One strange observation is when I have scope probes connected to the I2C lines it causes tons more NAKs. I have separate logic analyzer attached and might see a few NAK, then attaching oscilloscope probes to the lines causes many more. The signals look fine on the scope, just that the WM8731 is not pulling down for ACK, as if it's taking a break or something, 'i'm gonna sit this byte out'...