MSP430F5359: Do all of the I2C Bus ports operate using (the equivalent of) "open drain" drivers?

Hello,

Atlant Schmidt said:

I'm confident that they must be "open drain" (else the I²C Bus wouldn't operate
properly, especially for "clock stretching"), but I'd like you (TI) to confirm this
(and probably, to update the various documentation to reflect this).

That's correct.

Atlant Schmidt said:

I ask for this because we're having some trouble using an ST2378E magic
bidirectional level converter on the MSP430's I²C Bus. We operate our MSP430
at 2.5V and use this chip to accommodate the 3.3V connection to TI's EV2400
Battery Gauge programming pod. With the pod disconnected (i.e., open circuits
on the 3.3V side of the level translator, pulled-up by the chip's internal 9KΩ
pull-up resistors), we're getting intermittent cross-conduction, at least while the
MSP430 is trying to drive I2C SDA low. Because of this, I want to be absolutely
sure I understand the MSP430's pin architecture vis-a-vis driving the I²C Bus.

I'm assuming that you're powering VCC with 3.3V and VL with 2.5V. To rule out the level translator, why don't you run the MSP430 at 3.3V and connect to the EV2400 directly? If you still see the behavior, then I would review the USCI errata and make sure those aren't causing the issue. I would also review Section 5 Common I 2C Communication Issues in the Solutions to Common eUSCI and USCI Serial Communication Issues on MSP430 MCUs app note.

Atlant Schmidt said:

(As an aside, I also wonder if TI's TXS0108E version of the magic bidirectional
level converter works better than ST's version. If you've got any advice in that
regard, please feel free to offer it!)

They're quite similar actually. The ST2378E seems to have better ESD performance, but the TXS0108E seems to have lower current consumption, higher data rates and a lower minimum input voltage (low side).

Regards,

James

>(As an aside, I also wonder if TI's TXS0108E version of the magic bidirectional level converter works better than ST's version. 

I recently bought a sensor board from ST, and it used (ahem) the TXS0108E.

Bruce McKenney47378 said:

I recently bought a sensor board from ST, and it used (ahem) the TXS0108E.

But then again, my TI EV2400 Pod contains several ST2329As, the two-channel equivalent of that ST2378E. ;-)

James:

I've never suspected that there's anything amiss with the MSP430's I²C Bus interface (in this regard), although our electrical engineer wondered along those lines.

And now that you've confirmed that the MSP430 I²C Bus actually does real "open drain" operation (or a meaningful totem-pole equivalent), I can rest easier. It would be good if the documentation (both Data Sheet and Family User's Guide) stated this unambiguously, though.

We're going to try pulling OE (Output Enable) low on the ST2378E. We can't use that as a permanent solution (because we use other channels in that part for non-Battery Gauge purposes) but it will be a meaningful test. If that continues to point to the ST2378E as the bad actor, we'll figure out a proper change.

Either way, I'll report back and I thank you for your help so far!

Atlant

Thanks for the update, Atlant. Keep us posted on what you find out.

Regards,

James

James:

Thanks for your response!

We've now got pretty good proof that our "cross-conduction" problem is caused by a
small glitch from the I²C logic of the MSP430F5359 causing the ST2378E bidirectional
level translator to react badly. Over the weekend, with the ST2378E disabled, I ran
more than 10,000 cases of programming the Battery Gauge without any failures. 
We've also got 'scope shots that support this idea.

Here's the MSP430 driving I²C SDA in the absence of the ST2378E chip:

The Yellow trace is an analog representation of SDA and the Blue trace is an
analog representation of SCL. Note the little glitch in SDA as the MSP430
switches from emitting the "Start condition" to emitting the "Address Bit 0"
(with a value of "0" because this is the MSP430 addressing the Battery
Gauge at I²C address 0x16).

Here's what it looks like when the ST2378E is enabled:

You can see that the '2378 takes that brief little MSP430 glitch, activates its active
pull-up logic, and drives hard to pull SDA high while the MSP drives hard to pull the
line low. The result is that the (Yellow) SDA line stays mid-voltage until the MSP430
finally reaches a "1" bit in the address at which point the active driving logic in the
'2378 goes back to sleep. (The Green trace is the 3.3 V open-circuited side of the
ST2378E.)

The SDA glitch isn't mentioned in the MSP430F5359 Errata and frankly, it's hard for
me to get too excited about it because it's easy to see how the internals of the I²C
SDA logic could allow a few nanoseconds of "no drive" while switching from emitting
the "Start Condition" to emitting the first serial bit. If it weren't for the catastrophic
amplification of the glitch by the '2378, the I²C slave would ever notice the glitch.
If you feel it's worth mentioning the glitch to your engineers though, please feel free.
It might at least deserve mention in the Errata so no one else falls into this trap.

I think we're probably all set here. We'll solve this problem by re-engineering the
'2378 circuit so that the level translator is entirely disabled when the EV2400
pod isn't connected.

As a side note, it's likely that this problem wouldn't have occurred if we had chosen
TI's TXS0108E bidirectional translator versus ST's ST2378E. The TXS0108E Data
Sheet states that the active-drive one-shots only remain active for 30 ns whereas
the ST part apparently adopts a "keep actively driving until it gets there!" approach.
The TI part might have amplified the glitch but it wouldn't have prolonged it in time
to the point where it was several I²C bit times in length.

Thanks again for your help! If you don't have further questions or comments,
we can probably consider this issue "closed".

Atlant