This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TVP5150AM1 doesn't acknowledge I2C commands

Other Parts Discussed in Thread: TVP5150AM1

Hello all,

I'm currently working with a TVP5150AM1, which is placed on an own developed PCB. This PCB is based on the reference design in the TVP5150AM1 datasheet. Only difference made is a 22pF capacitor instead of a 33pF which I calculated. The whole design is powered by a Power supply with both 1.8V and 3.3V, no difference made between the 1.8V for the CH_AVDD, PLL_AVDD and DVDD, but ground is 'seperated' between Analog and Digital on the PCB as long as possible. When powerd up (PDN high, little delay, Reset high, little delay), the system works as it should. Clock (Crystal) is correct, as is the Pixel Clock Out. In this case, Video isn't even connected, so why there is a Pixel clock out is strange. However, not my issue.

Because I want to use the video data, I would like to set two registers by I2C. 0x00, 'video source selection' and 0x03, 'output enable'. As a result, I pulled the YOUT7/I2Csel to ground by a 10K resistor (however, the problem also exists with 10K to IO_DVDD, 3.3V). Therefore, the I2C write address B8h or 10111000b.The SDA and SCL are both pulled high to the 3.3V, tested with both 1.5K and 6.8K (1.2K according to specs not available. A 10K which is usually used neither, but I2C shouldn't care, so I don't care either).

I used a NXP LPC3141 (ARM) for I2C connection. This didn't work. According to the FAQ (http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=slea021), there should be a possibility that *after* an acknowledge the clock is held low. For I won't find that in the I2C specification, I assumed that that was the reason why it didn't work. My solution for that, develop an I2C core on a FPGA (Altera Cyclone 2, Cyclone II FPGA Starter Board). The core has been tested with an NXP PCA9635A, LED driver which is also used in the project, and works correctly. Modifing the core to send it to the TVP5150AM1 wasn't to hard either. Getting the TVP5150AM1 to acknowledge the sent data is. Whatever I tried, it doesn't work.

 

What I do on the TVP5150AM1 is the following:

PDN is set low, delay, and set high, Delay. Reset is set low, delay, and set high, Delay. The I2Csel should be read correctly. After that the data is send, in the following output on my scope (logic analyser not available):

SDA starts high, as SCL.

SDA is pulled low, delay, SCL is pulled low (start condition)

SDA is set to the first bit (1, therefore 'released'), SCL is 'released' but pulled down by the I2C slaves. After receiving and interpeting, the Videodecoder in this case, 'releases' this clock and the master recognizes this as data read and continues with the next bit. This is done 8 times (1 byte), in this case the address (7bit, 1011100) and RW bit (0).

After this data set, SDA is 'released' so the slaves can say 'acknowledge' or not by either pulling it down or don't touch the signal. After this, the clock is 'released' by every slave (one) and the SDA is read by the Master to find out if the device is either acknowledge or not.

And there it goes wrong, the TVP5150AM1 doesn't pull the SDA low, so it tells me it doesn't acknowledge the data, therefore the other data is irrelevant. However, I can't find where it goes wrong, why doesn't it acknowledge my commands (or at least it's own address).

 

The 3.3V and 1.8V are correct, measured by multimeter.

Crystal is correct, measured by scope.

Pixel clock is correct, measured by scope, I 'assume' that both DVDD and IO_DVDD is correct, therefore the Host Processor should also be able to receive and send data.

Because the SCL is wel pulled low and 'released' by the slave, the resistors (both 1.5K and 6.8K) should be working. Actually, I2C should be working.

 

If anyone has any solutions to make I2C work, or even a good direction, it would be great.

 

Thanks in advance,

Rolf

  • Hi Rolf,

    Can you tell me the frequency at which you are trying to operate I2C interface?

    Normally,I2C operates upto frequencies as large as 400KHz but for some devices it may be as low as 100 KHz or even lower for guaranteed operation. It maybe too fast for the slave to acknowledge.

    Have you checked your SCLK frequency?

    Regards,

    Sid

  • Hi Sid,

    I operate the I2C bus at approximately 100KHz (10uS/clock), it may vary a little waiting for the resulting data (waiting for the 'release' of SCL of the slave). I've also tested both 50KHz and 400KHz, but that wasn't a solution either. I sample the data at approximately 500KHz (50MHz clock / 100). However, in the I2C specification (http://www.nxp.com/acrobat_download/literature/9398/39340011.pdf), the maximum speed is irrelevant (maximum values are only given to fall and rise timing, which I'm able to achieve), and for minimum everything above 0 is good. Also, the slave would (should) use clock-stretching to slow the I2Cbus down to it's speed if required. I've also tested the 100KHz (and 400KHz) at the NXP LPC3141, which wasn't a solution either.

    I just wait until SCL is high (and therefore all slaves have done their thing with the data), and then I continue. But I'll try to verify the timings exactly to the I2C specification, until now I've only assumed it would be working (and used some delays, not good on FPGA designs). It's almost weekend for me, so I'll try to do that Monday morning as soon as possible.

    Thanks for your help so far.

    With kind regards,

    Rolf

  • The problem seemed to be either the capacitors around the crystal weren't working (22pF instead of 33pF), or the power supply wasn't stable enough. I fixed it at once. Anyway, it now works. Now the next implementation...

     

    I also noticed one 'small' thing. According to the FAQ of the TVP5150AM1 (http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=slea021, 3.4), After an acknowledge the clock is held low. In both tested I2C masters (Arduino and Embedded Artists LPC3141) this didn't work, and I didn't found that it is allowed in the I2C specification (but not read every word). I *really* had to write my own implementation.

     

    Rolf