• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 48 subscribers
  • Views 1885 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TVP5150 I2C Lockup at Init

Geoffrey Furman
Prodigy 50 points
Other Parts Discussed in Thread: TVP5150AM1, TVP5150, TVP5158

Has anyone seen this?  The TVP5150AM1 appears to hang the bus occasionally perhaps near startup.  It actually looks like it is driving at least one of the lines actively when high (push-pull instead of open drain.)

My I2c driver is a freescale micro.  It handles clock stretching.  I verified this with a scope.  RESET is pulled low and PDN is pulled high at startup when the power supplies come on.    I leave reset low the prescribed amount of time in the datasheet and add some margin for reliability.  When I drive reset high, I wait the prescribed amount of time in the datasheet and add margin for reliability.  My clock rate is 100KHz, I scoped the signals and meet all setup and hold times on the I2C.  I also have 15+ years with I2C so I think I know what we are doing.

I think this thing happens more often with both RESET and PDN low which is a reserved state so I stopped that but the problem keeps coming back and usually only when I am tweaking I2C related fucntions so it appears tweaky.  The lockup has always and only only occurred during a TVP5150 function and it is not the first transaction on the bus.

Thanks

 

  • 0
    TI__Genius 16810 points

    Geoffrey,

    Is it possible that SDL or SCL are transitioning before the TVP5150AM1 has completed reset?  The TVP5150AM1 I2C core can power up in a random state and could hang if an SDA/SCL transition occurs before the core is reset.  This could occur even if the TVP5150AM1 is not being addressed by I2C.

    I am not familiar with the freescale clock I2C capabilities, but the TVP5150AM1 does drive SCL low when the internal processor is busy.  The host must monitor this or provide adequate delay between I2C transactions. 

    When PDN is used, adeqate delay must be used following the low>high transiton to allow the crystal and internal clocking to stabililze before I2C communication.

  • 0 in reply to Larry Taylor
    Prodigy 50 points

    The freescale does handle clock stretching so that it tolerates the TVP holding SCL low.  Confirmed by o'scope.

    My reset timing and pulse duration is per TVP spec at power up and the I2C traffic is quiet per the same diagram.  I2C pulls high with the rise of the power suplies.

    I currently don't use PDC is pulls high (active) with the power supply)

    I will double check my timing.  Thanks.

  • 0 in reply to Geoffrey Furman
    TI__Genius 16810 points

    Geoffrey,

    What type of I2C writes are you doing when hang-up occurs - direct I2C or VBUS?

    Are you currently loading TVP5150AM1 patch code in your design?

  • 0 in reply to Larry Taylor
    Prodigy 50 points

    It is difficult to catch when and where becuase the fault is erratic.  We are loading the intial values, about a dozen in a loop as separate single byte writes (AddressWr, SubAddress, Data}

    The first is a write to 0x7f of 0x00.  The was in the reset section of a 2006 datasheet to "start the processor" but is not included in the latest datasheeet.

    In the latest version of the datasheets this is one of the patch registers and is NOT recommended in normal operation.

    We have never patched a device is 10 years.  So how do you know when you should patch the device?

    What do you mean by VBUS?  I don't see it in the datasheet.

  • 0 in reply to Geoffrey Furman
    TI__Genius 16810 points

    Sorry, VBUS access is indirect register addressing through I2C registers 21h-24h.

    Patch code version should not cause the I2C hang-up, I was just curious if you were going through the patch load process following power-up/reset.  The latest patch code and application note can be found at:

     http://focus.ti.com/lit/an/slea094/slea094.pdf

     http://software-dl.ti.com/dsps/dsps_public_sw/dsps_swops_houston/ANALOG_VIDEO/Analog_Video_Decoder_Versions.htm

    There were numerous perfomance enhancents included in the patch code.  If you are happy with current performance (other than I2C) you may not need this.  It won't help with your I2C problem.

    Writing to 0x7F restarts the CPU.  This is required following patch load, but should not be needed folowing hardware reset and execution from ROM code.  If this register is written to, a 200uS delay is required before the next I2C access. 

  • 0 in reply to Larry Taylor
    Prodigy 20 points

    Has this issue ever been solved?

    We are using the iMX536 along with the TVP5158 which is a superset to the TVP5150 and we are seeing this exact same issue on 3/100 boards built.  All timings have been verified and this failed transaction occurs on the very first access to the part right after boot.  Both SCL and SDA are guaranteed high durint reset, reset timing, clock, and power supplies have been tested and are well within specifications.  At the very end of the first transaction the TVP5158 drives SCL low and locks the bus and will not release that pin.  We have removed the tvp5158 from the bus and the lockups are eliminated, therefore we know that the lockup is caused by the tvp5158.

    We have added a Linux patch for the iMX536 and the issue still exists.

    Please provide a status update!

  • 0 in reply to Doug Martens

    I had the same issue. To resolve this, I put a 1Mohms at the input RESET PIN. I use a reset supervisor and I think that the rise time of the reset signal is too fast for the TVP5150AM. I think everybody that use an RC for the reset they had not problem with the I2C. I also try to put only a 0.1µF between RESET input and GND and it resolved the TVP5150AM1 init issue.

  • 0 in reply to albertelli vincent
    Prodigy 20 points

    Albertelli,

    Thanks for the suggestion.

    I have one board that failes to initialize the video encoder on about 60% of the boots.  I have tried to add the series resistor and capacitor and slowed down the reset rise time from nS to 10uS and the issue still exists.

    Any other suggestions would be appreciated.

    Geoffrey,

    You had experienced the same issue, did you ever find your solution?

    Thanks.