• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 31 subscribers
  • Views 561 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.

TMP441 soft reset

Jonas Nilsson
Prodigy 30 points
Other Parts Discussed in Thread: TMP441

We have an application where the tmp441:s i2c interface appears to hang following
a soft reset. It's stops emitting ACKs (or data for that matter) in future transactions.
In some cases it will recover, but most often, the failure persists and we can't
communicate with the device. This happens for individual devices, but far from all.

The time between the general call reset and the next i2c transaction is around 3ms.

Is the TMP441 immediately ready to accept a new transaction on the I2C bus
after a soft reset (I2C General call reset), or does it require a recovery time?

 

  • 0
    TI__Mastermind 18425 points

    Jonas,

    I am currently looking into this and will get back to you shortly.

  • 0
    TI__Mastermind 18425 points

    Jonas,

    I have discussed this with the design team. It will be helpful if you could provide us with the exact configuration that you have the device in.

    This includes:

    1. The voltage level you are using,
    2. pull up resistor values,
    3. the addressing that you are using (how are pins a1 and a0 connected)
    4. A scope shot showing the communication failing

    The reason we need a scope shot is to see when in the communication fails in the I2C transaction. This will provide a lot of insight for us. Please provide the communication speed along with this screen shot.

    We are going to perform a bench setup similar to yours once we have this information.

  • 0 in reply to Chris Featherstone
    Prodigy 30 points

    Hi Chris,

    Thanks for looking into this.

    VCC is 3.3V, which is applied ~1s before activity starts on the SMBus.
    Rise time of VCC is pretty much linear and monotonous and the
    ramp time is about 5ms.

    The SMBus has 1k pullups to VCC.

    I can't get a scope shot to you right now, because I have no failing system available
    to me at the moment. The failure is that there is no ACK of the address byte. This
    happens now and then. When it happens, this condition seems to persist: No future
    access attempts work until I power cycle. Conversely,if the first access succeeds,
    there are no future failures either.

     

    Jonas

  • 0 in reply to Jonas Nilsson
    Prodigy 30 points

    Hi Chris,

     

    Any news on this?

    Jonas

  • 0 in reply to Jonas Nilsson
    TI__Mastermind 18425 points

    Jonas,

    I currently have the designers involved and they are looking into this issue for us. I will get back to you soon regarding this issue. Have you come across any more failing units?

  • 0 in reply to Jonas Nilsson
    TI__Mastermind 18425 points

    Jonas,

    I had a meeting with the design manager. There are a couple of items that will be useful in debugging this issue.

    1) We can use a scope shot of the address pins after a general call reset. This can come from a good unit. This will be used to determine how long it takes for the address pins to settle.

    2) There are two ways to perform a software reset. One way is to write any value to the Software Reset Register and the other is to reset via the Two-Wire general call reset. It's important for the designers to know which method is being used.

    3) The communication speed is important to know. If you could send us a scope shot of a temperature read from a good unit showing the SDA and SCL lines this will help provide more insight to the design team.