Due to the U.S. Thanksgiving holiday, please expect delayed responses during the week of 11/22.

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.

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

Part Number: MSP430F5359
Other Parts Discussed in Thread: EV2400, TXS0108E

Folks:

The MSP430F5359 has three USCI peripherals (USCI_B0, USCI_B1, and USCI_B2) that can
operate in I²C Bus mode. USCI_B0 appears on the P2 "Portmap" pins; USCI_B1 appears on
P8.5 and P8.6, and USCI_B2 appears on P9.5 and P9.6.

For USCI_B0, the Data Sheet makes it explicit that I2C Clock and I2C Data are "open drain"
signals. (They could be real open-drain drivers or just a clever simulation that only switches "on"
the totem pole when "driving low"; it makes no difference.)

But for USCI_B1 and _B2, both the Data Sheet and the Family User's Guide are relatively
silent on whether or not P8.5 and P8.6 or P9.5 and P9.6 become "open drain" drivers when
the USCI peripheral is selected and placed into I²C Bus mode. We have this diagram in the
Family User's Guide that illustrates "open drain" drivers:

But no other mention of "open drain" except in the context of the "Port Mapping" functionality.

And the Data Sheet offers up this diagram for the P9.x pin circuitry (and an equivalent
diagram for the P8.x pin circuitry):

Again, no obvious clue that the P9.5 and P.6 pins (or P8.5 and P8.6 pins) can be
"open drain" when the pins are operating in I²C Bus mode.

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).

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.

(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!)

Atlant

  • 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

  • Hi Atlant,

    Thanks for the very detailed reply. I wish everyone was as thorough as you!

    I can't say that I've ever noticed a glitch like you're observing, but it does seem like your description of the ST2378E's behavior is accurate. I was curious if anyone else has ever noticed a glitch like this, and surprisingly, I found several threads discussing it (there are probably more).

    In a nutshell, the glitch does seem to stem from a change in the I2C state machine between the start bit and first data bit. An interesting workaround is to use an odd address for the secondary device rather than an even address. Also, the glitch on SDA occurs after SCL transitions from high to low which seems to be allowable according to the I2C spec based on Jens-Michael Gross's comments in the first thread. BartW also summarized the recommendations and described how they worked for them. You may find that interesting.

    Your approach sounds like it works, but you could also just use 3.3V as the MSP430 supply voltage and not need a translator at all. Lastly, we do offer some devices with 5V-tolerant I/O's in case that would help your design.

    Regards,

    James