• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 30 subscribers
  • Views 393 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.

Original question:

TMP112: General call reset command

TMP112: in not working condition after 10 days

Michael9q
Intellectual 565 points
Part Number: TMP112

Howdy there,

we use TMP112 (TMP112NAIDRLR) for temperature monitoring in our system. We did long term measurement of 5 units at room temperature with read out temp every 60 sec. Occasionally there is lost of the I2C communication with the TMP112. It freezes this periphery without any further use until next power cycle. This happen after 7 days and 10 days at two different units.

Could you please help us understand why there is lost if communication with the TMP112

It is strange that it appears suddenly after quite long time (approx. 1M sec.). This significantly decrease our reliability.  

Meanwhile there has been implemented recovery sequence which behaves as followings:

If the I2C controller stops to work, after 100ms is activated recovery mode, or if NACK is received then it is activated immediately.

Recovery sequence: the entire I2C is switched off, pins SCL and SDA are pulled down to 0 for 90msec, this should restart the TMP112. Then there is reinitialization of the I2C controller, configuration of the TMP112 is newly set for case of lost settings.
The attempt for recovery is done once after each unsuccessful attempt – every 1000ms.

This is used schematics:

Please let us understand why this is happening.

Thanks,

Best Regards,

Michael 

  • 0
    TI__Mastermind 43730 points

    Hi Michael,

    Do you have any logic analyzer captures when the transaction fails?  Also, what I2C clock frequency is used?  

    Also, is there a reason your bypass capacitor is so large?  The datasheet recommends 0.01uF.

  • 0 in reply to Eddie LaCost
    Intellectual 565 points

    Hi Eddie,
    you are right! The cap size is 1000x larger than recommended. I did not see this previously. Do you think this may cause some resonance or power shock on the TMP112? I am going to check why we have this value.
    I do have logic analyzer. I will sniff I2C communication and try to see the problem again.

    For the I2C we use 100kHz. That should be well in the fast mode of I2C (0.001 - 0.4 MHz).

    Thanks,

    Michael 

  • 0 in reply to Michael9q
    TI__Mastermind 43730 points

    Michael,

    I wouldn't immediately think that the larger bypass value would cause a major problem with the device, but it is outside the datasheet recommended value by quite a bit.  In addition to looking at the logic analyzer, I recommend changing the bypass cap value on one of the devices that consistently fails and see if you are still able to reproduce the problem.  

    Yes, 100kHz is fine.

  • 0 in reply to Eddie LaCost
    Intellectual 565 points

    Hello Eddie,

    we setup measurement of data lines. If no ACK is received within 3 sec then it stops to measure. 
    Do you think that this is sufficient resolution to understand the root cause of the problem?

    Section for 10s with data received every 1 sec:

     

    Zoomed section at each data received in every 1 sec.

    Thank you,

    Best 

    Michael 

  • 0 in reply to Michael9q
    TI__Mastermind 43730 points

    Hi Michael,

    Do you have any kind of cabling on the I2C lines?  I2C is prone to picking up noise, so it's possible that noise is causing an intermittent issue getting picked up in the cabling.    

  • 0 in reply to Eddie LaCost
    Intellectual 565 points

    Hello Eddie,

    coming back to the topic. I was able to reintroduce the error. EMI in surrounding area makes it fail. Please see following captured data at six units with TMP112. Unit no. 4 failed in this data set. 

    Do you have any suggestion what the EMI do to the I2C controller and what should be appropriate solution to fix this? 

    Recovery sequence for the I2C controller through the timeout does not seem to me as right solution but more as the top up safety feature only.

    There is shield all around the I2C lines. They are shorter then 1/2". 

    Do I miss something important here?

    Thank you,

    Michael 

    Last transferred data 

    disturbances appeared on clock:

    This is the layout:

  • 0 in reply to Michael9q
    TI__Mastermind 43730 points

    Michael,

    You may also see better EMI immunity performance using heavier pull up resistors.  This just needs to be limited to 3mA, so you could try ~2k ohms.  I am also checking for other recommendations and will let you know.