Post Go back to editing

AD9889 I2C ACK at wrong address

I’m experiencing problems with I2C communications to the AD9889B sitting on my Blackfin BF547 TWI port (new design and first time with an AD9889).

  Circuit overview:

  The AD9889, Blackfin and 2K0 pull-ups to 3v3 are the only things on the bus.

  Track length about 50mm each and a 500MHz (5GSa/s) scope shows the waveforms to be clean.

  The SCL high and low periods are a tad over 8us giving 54KHz bit rate.

  The AD9889 PD/A0 pin is pulled high via a 2K0 thus its I2C address should be 0x7A.

  I'm not using the audio features so pins 7 to 14 (LFCSP) are all pulled low (SPDIF,MCLK,I2S[3:0],SCLK and LRCLK)

  I've not yet configured the digital video stream hence DE, HSYNC, VSYNC and CLK (pin 6) are all low.

  I'm not using the HDCP EEPROM facility so their lines MDA,MCL are pulled high via 2K0

When I failed to get an ACK at 0x7A for both reads and writes I wrote a short routine to "poll" each I2C address from 0x00 to 0x7F,

I get an address ACK at addresses 0x38, 0x3D and 0x3F but nothing from 0x7A (or anywhere else), verified using the scope, the 9-bit "packets" look like these:

  SDA = 011100010 (address 0111000, RD, ACK)

  SDA = 011110110 (address 0111101, RD, ACK)

  SDA = 011111110 (address 0111111, RD, ACK)

I then repeated the test with PD/A0 pulled low, the address should then be 0x72 but oddly I get an ACK from the same three addresses.

As I didn’t have an HDMI lead and monitor I expected limited response so tried pulling HPD to 5v and that made no difference, same 3 addresses ACK.

Finally, just to be sure the Blackfin wasn’t the source of the ACK I chopped the AD9889 SCL and pulled it high at the chip, now no ACKs so it’s definitely the AD9889 doing the ACK-ing, track repaired and boss hanging over me waiting for progress.

I've attached the scope screen dump for an ack'd wrong address, two for nACK'd correct addresses plus the AD9889 block of circuitry (mini-HDMI connector)

Any clues anyone?
Parents Reply Children
No Data