• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 3 answers
  • Subscribers 31 subscribers
  • Views 1601 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMP007: reset and recovery timing

H.W.
Prodigy 70 points
Part Number: TMP007
Other Parts Discussed in Thread: TMP101

I've by now successfully integrated a TMP007 but I can't seem to find any info on power-on reset and software reset timing in the datasheet and the device only works propely when long delays are introduced - which doesn't feel right.

Our device firmware does some I/O testing to detect stuck high, low and shorted I2C lines, ends with a stop condition, then proceeds with attempted read / write operations to detect other devices (MCP4827, TMP101) and initializes those. I2C clock is 100kHz.

TMP007 devices are scanned by sending address + write and a test for ACK, followed by a stop condition. 

bool TMP007Device::detect(void)
{
	i2c_c_write_start(_addr ); 
	bool ack = i2c_c_getAck(TW_MT_SLA_ACK);
	i2c_stop();
	return ack;
}

Some of the preceding bus transactions, the detection itself or the issuing of a software reset cause the device to NACK further immediate commands. None of these contain bus errors. Only when delays (e.g. 40ms) are introduced between the stop and subsequent start conditions this behavior is no longer seen.

What am I missing?

  • 0
    Prodigy 70 points

    further testing shows the excessive t_BUF between 1.5 and 2ms is sufficient.

  • 0
    TI__Mastermind 35895 points
    What exactly is the device doing that is undesirable? I need to understand your definition of "works properly."

    Note that on power-on, the device should be able to communicate immediately when the minimum voltage is met. However, the device takes hundreds of milliseconds to complete its first temperature measurement (known as an ADC Conversion and specified as Conversion Time.) It's not until after this first measurement completes that the temperature registers will be populated.

    Ren
  • 0 in reply to Ren Schackmann
    Prodigy 70 points

    Ren, my issue is on a very basic level where the I2C communication won't work. Here's how the communication looks when everything is ok - imagine no delays at the black lines will cause all transfers below line 71 to NACK:

    pull-up resistors are both 1k, VCC=5.0V. Data also looked ok on the scope; the above decoding was obtained with an Open Bench logic sniffer.

  • 0 in reply to H.W.
    Prodigy 70 points

    ok line 68 for that matter despite the device being connected properly.

  • 0 in reply to H.W.
    TI__Mastermind 35895 points
    The detect transaction is likely causing a bus time out. You should complete this transaction instead of attempting to STOP after the Address phase. The timeout will last 30ms unless you provide sufficient clocks to unlatch it.

    Ren
  • 0 in reply to Ren Schackmann
    Prodigy 70 points

    regardless of delay time (2 ms delays seem to work, too), any preceding transfers should not cause TMP007 to go into that "fault" state (which is what I remember having observed as well).
    I suspect something fishy with DC offset and not safely reaching the 0.4V for a logic low state.

    In the meantime, is there any buffer time between a software reset and the next I2C command?

  • 0 in reply to H.W.
    TI__Mastermind 35895 points
    No, there should not be any buffer time between software reset and I2C transactions.

    Ren