• TI thinks resolved

TMP007: reset and recovery timing

Part Number: TMP007

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?

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

  • 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
  • In reply to Ren Schackmann:

    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.

  • In reply to H.W.:

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

  • In reply to H.W.:

    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
  • In reply to Ren Schackmann:

    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?

  • In reply to H.W.:

    No, there should not be any buffer time between software reset and I2C transactions.

    Ren