• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 2 answers
  • Subscribers 31 subscribers
  • Views 502 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.

TMP006 address NAK until power cycle (device disappears from bus)

John Scott57
Intellectual 385 points
Other Parts Discussed in Thread: TMP006, HDC2010

We are using the TMP006 in a production/volume application as well as a number of other TI parts.

I understand that the TMP006 is no longer manufactured however we have an issue with the part that is causing us some headaches and we need to continue to support it. We have a stockpile of these parts and are continuing to use them in production.

The symptom is that some devices will be working fine, then become entirely non-responsive. Other devices on the bus are fine and show no problems but the TMP006 can not be talked to and all attempts to contact it result in a NAK. The symptoms persist until the device is power cycled.

We have tried the usual device recovery procedures to no avail. We have also tried using all the alternative addresses per the data sheet, in case the ADR pins were experiencing some sort of issue. The fact that the only way to recover the device is to power cycle it leads us to believe it must be in a stuck state.

We have also observed this same behaviour on the TMP007.

We have not figured out a way to replicate the issue.

  • 0
    TI__Mastermind 43815 points

    Hi John,

    Please show me oscilloscope pictures of your bus. 

    thanks,

    ren

  • 0 in reply to Ren Schackmann
    Intellectual 385 points

    As part of our testing/viewing, we perform a bus reset (app note AN-686) by clocking out any potential remaining bits on the bus, followed by a STOP. SDA is never held low, so we do not believe there are any stuck devices.

    We then attempt to read the manufacturer ID register, but get an I2C address NAK. The device has both ADDR pins pulled low via 10K resistors, so the address is 0x40.

    As an example of a successful transfer, here is a another device on the bus, the TI HDC2010, which we can talk to without issues.

    All transactions usually run at 400KHz, but we slowed the bus down for this test to ensure maximum signal integrity.
    We have tried all possible addresses for the TMP007 (0x40 thru 0x47 inclusive) and do not see any response.
    After power cycling the device, communication works as expected, here is an example good trace at our usual 400KHz
    Hopefully this makes sense and let me know if here are any questions. As I mentioned this has been quite a headache for us. The device is not recoverable and other devices on the buss continue to function. Power cycling is not an option for us.
    Thanks.
  • 0 in reply to John Scott57
    TI__Mastermind 43815 points

    Hi John,

    You can bias a digital input to logic high using a resistor to supply, but it doesn't work the other way around. You can't use a 10kohm to GND to ensure logic low is detected. Please use a 0ohm resistor. 

    thanks,

    ren

  • 0 in reply to Ren Schackmann
    Intellectual 385 points

    Thanks for the fast reply Ren,The TMP006 datasheet specifies the Logic input current as +-1uA. With such a high input impedance, a 10k pulldown should be able to provide almost 10x the required current to keep the input pulled below logic low @ 0.8v.

    This isn't really my area of expertise, have I misread the datasheet?

    Regardless, we have jumped the stuck device's address lines to 0V via 0 ohm resistors. The problem remains. Should this have fixed it?

  • 0 in reply to John Scott57
    TI__Mastermind 43815 points

    John,

    Are you saying the problem only occurs when you precede communication with the bus reset sequence? I'm not sure why TMP006 would be sensitive to this, but that may be all there is to it.

    thanks,

    ren 

  • 0 in reply to Ren Schackmann
    Intellectual 385 points

    ren,

    No, we have yet to find a consistent replication scenario. We perform the bus reset sequence to be absolutely certain that a stuck transaction has not convinced the TMP006 to remain silent.

    If we can provide a replication scenario, will you be able to investigate this more?

    Cheers,

    John

  • 0 in reply to John Scott57
    TI__Guru* 91206 points

    John - 

    Would it be possible to share your schematic or at very least show the TMP006, the pullup resistors and any directly associated circuitry?

  • 0 in reply to Josh Wyatt
    Intellectual 385 points

    Just wanted to get in a reply so this isn't auto closed. We're narrowing in on the problem. It seems like it has something to do with the fact that we reset the device during each read.

    We noticed that the TMP007 datasheet mentioned that a device reset disables the serial interface for ~3ms while it reloads default config into the internal registers. We are writing the reset bit on the TMP006 and suspect it may be locking up due to the reset procedure. Tests are ongoing, we'll update as we find more.

    Josh - we can share a screenshot of the TMP006 as well as pull up resistors but it's fairly boring. I'll get back to you soon.

  • 0 in reply to John Scott57
    Intellectual 385 points

    I should say that we discovered this by changing our read procedure to not reset the device and we haven't had a lock up since.

  • 0 in reply to John Scott57
    TI__Mastermind 43815 points

    John,

    Please note that the TMP006 needs 250ms to perform measurements. After a reset, there will not be valid temperature data to retrieve until the first measurement completes. 

    thanks,

    ren