SPI AD5206 is not reading all 1 bits and leading zeros

Hi all,

So after a couple hours of troubleshooting, I'm stumped. I currently have the AD5206 controlling a couple op-amps using an Arduino Mega, with the following sample code:

#include <SPI.h>

const int slaveSelectPin = 52;

void setup() {

  pinMode(slaveSelectPin, OUTPUT);
  Serial.begin(9600);
  SPI.setClockDivider(2);
  SPI.begin();

}
void loop() {
  
  for (int channel = 0; channel < 6; channel++) {

    digitalPotWrite(channel,64); // should be slightly more than 25% on
    delay(1000);
    digitalPotWrite(channel,63); // should be 25% on
    delay(1000);

  }
 
}

void digitalPotWrite(byte address, byte value) {
  
  digitalWrite(slaveSelectPin, LOW);
  SPI.transfer(address);
  SPI.transfer(value);
  digitalWrite(slaveSelectPin, HIGH);

}

Now this is what I'm using to test with my audio interface. The issue is, the AD5206 doesn't seem to be recognizing any independent '1' bits or any leading zeros.

For the above example code, I have audio hooked up to channel 1 (address '010') but am consecutively pulsing a 64 out of 255 (0100 0000) and 63 out of 255 level (0011 1111) on each of the 6 channels. Hypothetically, I should be hearing about the same volume on each channel with such a minor change.

The actual result: when I send the 64, I hear no audio. When the 63 is sent, audio is heard at about 25%. Additionally, it doesn't seem to recognize the leading zeros, so I get audio changes when sending values for multiple channels. The results look like this

channels go from 0 - 5

Channel Level Bits Sent Observed Result
1 64 00101000 00000000 Audio Stops
2 63 01000111 11100000 Audio Heard
4 64 10001000 00000000 Audio Stops
4 63 10000111 11100000 Audio heard
5 64 10101000 00000000 Audio Stops
5 63 10100111 11100000 Audio Heard

So as you can see, ~except for the leading '1' address bit~ any standalone '1' and all leading zeros seem to be unrecognized by my AD5206. Thats why I'm able to change the level on channel 1 when sending data for channels 1,2, 4, and 5, (001, 010, 100, and 101 respectively), because the first three look like '010' without the proper leading zeros and '101' looks like '100' when it's missing the last '1' bit.

Additionally, I'm able to reproduce this for a level values 64, 32, 16, 8, etc: they all dont pass audio, but subtracting 1 from the level brings the expected audio level. The same happens for level 128, except for channels 1 and 5, because the MSB in '1000 0000' is consecutive to the last '1' bit of the address, making it readable by the AD5206.

So this is as much analysis as I could think to do, and I'm still stumped. Anyone with experience on this? You can see my attachment of my oscilloscope reading, which puts the CLK and SDI signals according to spec.

Any help would be greatly appreciated, thanks everyone!

Pat

From the datasheet

Eleven data bits make up the data-word clocked into the serial input register

How many bits are you sending? Looks like 16.
Take a look at the timing diagram on page 5.

Page 15: "The last 11 bits of the data-word entered into the serial register are held when CS returns high."
Two SPI.transfers() seems correct to me. The first 5 bits (upper bits of address) get ignored, the 8 bits of value should get used as the level set.

You are sending data to channels 0 and 7. 0 to 5 should be used. xxxxx000 to xxxxx101 for address.

I realized what my problem was...

CrossRoads:
Page 15: "The last 11 bits of the data-word entered into the serial register are held when CS returns high."
Two SPI.transfers() seems correct to me. The first 5 bits (upper bits of address) get ignored, the 8 bits of value should get used as the level set.

You are sending data to channels 0 and 7. 0 to 5 should be used. xxxxx000 to xxxxx101 for address.

I had initially been sending two bytes with leading zeros but was getting weird results too. But I didn't realize this part of the data sheet that says it uses the last 11-bits...

So I reverted back to that old code of sending one byte with the address, the other with the level. It got better, but still unstable. After looking at the data sheet, I wanted to see if the CS timing was right, so I plug in the oscilloscope. Hmm, thats weird. Why is my CS pin pulsing at the same frequency as my CLK?

Oh thats right.. Coming from working on the DUE for the past year or so to the MEGA made me forget that trying to use pin 52 as a regular I/O pin isn't such a good idea when using SPI :slight_smile: So I changed my CS to another unused I/O, and it works beautifully now.

I'm just surprised that it worked as well as it did considering my CS was just repeating the clock..

Thanks @CrossRoads and @SurferTim for you help!

Pat