NXP i2c temperature probe locking up

i2clevel-shiftingtemperature

I have an issue with an NXP SE95 temperature probe that has been working just fine up until now on other systems. At some point, either on boot or soon after, the probe will have some sort of meltdown and hold SDA low until power is cycled. I have a PIC microcontroller on the same bus and it is ok. I'm running at 3.3V (probe's voltage range is 2.8 – 5.5V)

I have two of them and both behave in the same way. They are connected to an OMAP4430 (Gumstix Duovero) through an isolating level shifter of this design:

enter image description here

Edit: This turned out to be a red herring and the lockup was unrelated to the level shifter.

I believe the 4.7k pull up is adequate here – it gives a rise time in the 700ns region. Not particularly fast but within spec. The Gumstix has pullups on about 1k0 so the 10ks are superfluous really.

I've used the same probe on a different ARM (at 3.3V, no level shifter) and from a PIC without issue. Is there something wrong with using a level shifter like this? I cannot see any reason why the probe should lock up. It does this without its own address ever being transmitted.

Best Answer

For completeness I'll answer my own question.

This appears to be a chip problem. My revision of the datasheet does not mention lock up issues but the versions of the datasheet on the NXP website do. This is a lesson to get the datasheet from the manufacturer, not from a link on Farnell or Radionics.

Section 14. Application information now reads:

The SE95 is sensitive to power supplies with ramp-up time <2 ms and could NACK or hang the I2C-bus.

If the power supply ramp-up time is <2 ms, use an RC network with R = 300 ohms C = 10 uF, as shown in Figure 18, to add about 3 ms to the ramp-up time.

I switch the power to the chip via a MOSFET after making sure the 3.3V is stable. The chip is decoupled with 100nF and is often the only one on that line so the rise time is very fast.

There you go. Not the first time I've seen stackexchange posts which turned out to be chip errata. Microcontrollers are especially ones to check very closely.