We have an application where the tmp441:s i2c interface appears to hang followinga 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'tcommunicate 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 busafter a soft reset (I2C General call reset), or does it require a recovery time?
Jonas,
I am currently looking into this and will get back to you shortly.
Best Regards,Chris FeatherstoneLinear Characterization EngineerHigh Performance Linear Products
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:
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.
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 theramp 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 availableto me at the moment. The failure is that there is no ACK of the address byte. Thishappens now and then. When it happens, this condition seems to persist: No futureaccess attempts work until I power cycle. Conversely,if the first access succeeds,there are no future failures either.
Jonas
Any news on this?
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?
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.