AnsweredAssumed Answered

I2C Clock Stretching Support

Question asked by yanava on Sep 21, 2011
Latest reply on Sep 21, 2011 by yanava

I'm currently debugging an I2C device that is connected to my ADSP-21469 processor in a custom board. The SHARC processor is beeing used as the master of the I2C transaction, while the device I'm trying to use is the slave. The connection is ok, proven and working, as the device responds ok to my commands (during one step of the process). The SHARC is running at 400MHz, with no further alterations to the PLL.


The device's address (with the R/W bit) is 0xC2 for write and 0xC3 for read. In SHARC I have to enter the 7 bit address, which is 0x61.


I'm using a polling strategy to operate the I2C, as I prefer to have closed Send / Receive functions, instead of issuing a receive and collect data later. I might change that in the future, because I2C is quite slow.


The problem I have is with I2C clock stretching. According to the manufacturer, this particular device I'm interfacing to (a TV tuner, the XC5000 from Xceive to be more precise) has 2 different I2C behaviors. It's more or less like a processor. When it's booting the I2C interface is fast, and supports 400kbps mode. I verified this by configuring my hardware to operate at 400kbps. Everything works fine. When the boot finishes, the device has a series of internal registers I can access, but they are soft registers, which means they're slower than a hardware register. Acording to the manufacturer, a response can take up to 0.1ms to be processed when the device is operating normally.


Still acording to the manufacturer, if the device is busy, clock stretching is used.  This means that during the I2C transfer, the slave will hold the SCL line down, so the master will slow down things a bit. In the particular transfer I'm dealing with this should happen on the Address phase of the I2C transaction. What I do see in my scope is that the SHARC ignores this, put the clock line on HIGH and issues a ANAK condition. I tried this with the I2C clock in various speeds, right until around 65-70kHz, in which everything works fine.


My question is: do I have to run that slowly or is there a way to wait for the host to respond?


Attached you will find:


1) The schematics for my DSP board (which contains the SHARC processor). I cannot provide schematics for the XC5000 board, because this device is protected by an NDA. I can assure you though that the connection works properly. The device is interface via a connector, in page

2) Sample source code that I'm using to debug my I2C application (I use a simple DAI config to implement a chip select for the tuners)

3) Scope prints showing one transfer performed during the boot phase (which is going ok!) and a register failed to read.  The same register has a sucessfull read if the transfer is made @ 67kHz. For some reason my scope parses the address as 0x61 sometimes and 0xC2 in others.


Best regards.