For the past week or so I have been trying unsuccessfully to use a WM8731 codec with a T3.6. Others are having the same problem and it is actively being discussed in another thread. I have started this new thread because I believe the issue might be more general than just communication with this particular chip.
I have built a AudioBoard compatible plugin board with a WM8731 mounted on an AdaFruit 28 pin TSSOP breakout board. The circuit is basically the same as the Mikroe WM8731 board, but uses only LINEIN and LINEOUT. Here's the thing, it works great with a T3.2 but fails absolutely on a T3.6. The problem is obviously in the I2C communication to load the 8731 registers. The I2C code reports a NACK error on every write, regardless of I2C rate, CPU frequency, or value of the SDA and SCLK pullup resistors (from 1k to 10k). Here are a couple of sample programs that work with the 3.2 but not the 3,6. First, the Hardware example code from Teensy WM8731PassThroughStereo.ino:
It works just great on the T3.2, the output reflects the input with a 12dB gain. A nice, clean output. This example fails completely with the 3.6.
So I went back to basics with the Wire library, and wrote the smallest code I could that would illustrate what is going on. Here it is, it simply loops withe a beginTransmission()- endTransmission() loop,
Note 0x1A is the address of the WM8731. I then looked at the SDA and SCL lines on my mixed-mode 'scope. Here's what I got on the T3.2,
If you decode the packet, the addres byte is 0011|0100 = 0x34 which is 0x1A<<1 which is correct, and then the 9th bit (R/W) is 0 which indicates a write from the master, which is also correct. The short blip at the end is the ACK from the WM8731. So all is good in T3.2 land.
If we simply transfer the codec (and code) to a T3.6 board, we get a different story.
Here I stored the T3,2 SDA waveform from above as a reference, and it is shown in blue for comparison. The 3.6's SDA is yellow, and the SCL is again pink. If you decode the SDA it is 0x34 as it should be, BUT note that the 9th bit is now a 1, and there is no ACK blip from the codec! Where did that high R/W bit suddenly appear from? Something is wrong here, and it is no wonder we are not getting ACKs, indicates the WM8731 is not awake and listening for data. Sure enough, if I include data bytes as part of the packet I don't see ACKs for any of them.
I have tested this on three T3.6's with the same result.
In addition I tried running the T3.6 with a bit-banged I2C library and it worked. I don't have screenshots to show this, but the R/W bit was low.
My conjecture is that the inverted R/W bit in the Wire.beginTransmission() is probably causing the problem.
Could it be that the 3.6 is using WireKinetis.h and WireKinetis.cpp and the 3.2 is using Wire.cpp and Wire.h? What makes me really puzzled is that I use the Wire library to talk to other I2C devices on T3.6's, and surely such a potentially serious bug would have shown up by now??? Is the WM8731 a particularly "picky" device?
I have built a AudioBoard compatible plugin board with a WM8731 mounted on an AdaFruit 28 pin TSSOP breakout board. The circuit is basically the same as the Mikroe WM8731 board, but uses only LINEIN and LINEOUT. Here's the thing, it works great with a T3.2 but fails absolutely on a T3.6. The problem is obviously in the I2C communication to load the 8731 registers. The I2C code reports a NACK error on every write, regardless of I2C rate, CPU frequency, or value of the SDA and SCLK pullup resistors (from 1k to 10k). Here are a couple of sample programs that work with the 3.2 but not the 3,6. First, the Hardware example code from Teensy WM8731PassThroughStereo.ino:
Code:
/*
* A simple hardware test which receives audio from the audio shield
* Line-In pins and send it to the Line-Out pins and headphone jack.
*
* This example code is in the public domain.
*/
//*** Works on T3.2 but not 3.6 ***
#include <Audio.h>
AudioInputI2S I2Sin;
AudioOutputI2S I2Sout;
AudioConnection c1(I2Sin, 0, I2Sout, 0);
AudioConnection c2(I2Sin, 1, I2Sout, 1);
AudioControlWM8731 codec;
void setup(){
AudioMemory(12);
codec.enable();
codec.inputSelect(AUDIO_INPUT_LINEIN);
codec.inputLevel(1.0);
}
void loop(){}
So I went back to basics with the Wire library, and wrote the smallest code I could that would illustrate what is going on. Here it is, it simply loops withe a beginTransmission()- endTransmission() loop,
Code:
#include <Wire.h>
void setup() {
Wire.begin();
}
void loop() {
Wire.beginTransmission(0x1A);
Wire.endTransmission(true);
delayMicroseconds(200);
}
Note 0x1A is the address of the WM8731. I then looked at the SDA and SCL lines on my mixed-mode 'scope. Here's what I got on the T3.2,
If you decode the packet, the addres byte is 0011|0100 = 0x34 which is 0x1A<<1 which is correct, and then the 9th bit (R/W) is 0 which indicates a write from the master, which is also correct. The short blip at the end is the ACK from the WM8731. So all is good in T3.2 land.
If we simply transfer the codec (and code) to a T3.6 board, we get a different story.
Here I stored the T3,2 SDA waveform from above as a reference, and it is shown in blue for comparison. The 3.6's SDA is yellow, and the SCL is again pink. If you decode the SDA it is 0x34 as it should be, BUT note that the 9th bit is now a 1, and there is no ACK blip from the codec! Where did that high R/W bit suddenly appear from? Something is wrong here, and it is no wonder we are not getting ACKs, indicates the WM8731 is not awake and listening for data. Sure enough, if I include data bytes as part of the packet I don't see ACKs for any of them.
I have tested this on three T3.6's with the same result.
In addition I tried running the T3.6 with a bit-banged I2C library and it worked. I don't have screenshots to show this, but the R/W bit was low.
My conjecture is that the inverted R/W bit in the Wire.beginTransmission() is probably causing the problem.
Could it be that the 3.6 is using WireKinetis.h and WireKinetis.cpp and the 3.2 is using Wire.cpp and Wire.h? What makes me really puzzled is that I use the Wire library to talk to other I2C devices on T3.6's, and surely such a potentially serious bug would have shown up by now??? Is the WM8731 a particularly "picky" device?