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.

Setting PxREN.y for MISO pin?

Other Parts Discussed in Thread: MSP430F5529, MSP430F5510

There seems to be an internal conflict inside the MSP430 that causes a 4-5mA draw when using the internal pull-up/pull-down resistor for the MISO pin.  The problem description is long, but here goes.

I'm using MSP430F5529 as master on an SPI bus with several peripherals.  I use PxREN.y to enable the pull-down resistor on the MISO pin so there won't be an open input when none of the slaves is driving MISO.  I also reconfigure the pull-down temporarily as a pull-up when assessing the health of a slave that always transmits a particular bit as a zero.  I have used this configuration for a few years now without noticing any trouble.  (Testing is pretty thorough around here.)

Today, while testing a new design with Rev E MSP430F5529, I noticed 4-5 mA of unexpected current.  I stopped the MCU with a debugger and probed around with my scope.  I found the MISO line sitting at Vcc/2 (not good).  I doubled checked register values inside the MSP430 to make sure the MSP430 wasn't driving MISO as an output.  I double checked chip select signals around the board to make sure none of the slaves were driving MISO.  Then I let the MCU run and watched some SPI waveforms which looked like the MSP430 pull-down resistor was pulling to Vcc/2, but only about half the time.  (The other half of the time it pulled to Vss as expected.)  There was the telltale RC curve from Vcc steering to Vcc/2.  So the Vcc/2 source appeared to be inside the MSP430.

After stopping the MCU again in the debugger, I noticed I could make the 4-5mA go away merely by disabling the pull-down resistor (PxREN.y = 0).  I could also make it go away by taking pin control away from the USCI (PxSEL.y = 0).  Either change (all while the MCU was otherwise stopped) would eliminate the extra current.  Putting PxREN.y back to 1 would bring the extra current back, but putting PxSEL.y back would not bring the extra current back.  The extra 4-5mA was positively tied to the state of MISO being Vcc/2 instead of the expected state of Vss.

I can only guess that the switching that allows either DVcc or DVss to anchor the pull-up/pull-down resistor is somehow allowing both, which is connecting DVcc to DVss through the switching.  That would account for the 4-5mA.

This is our first experience with Rev E of the 'F5529.  We've finally gotten through all our old Rev D parts.  Now I'm highly suspicious of the Rev E parts!  However, this is also a new design so I'm highly suspicious of my own work too!

Does anybody else use the pull-up / pull-down in the same way I do on MISO?  I'm starting to think maybe the USCI is too smart and is trying to protect itself from an open input in some other way.  Maybe I just can't use PxREN.y with SPI?

I have more experimenting planned for tomorrow, but I'm hoping somebody has some insight perhaps into an error in my configuration or my testing methodology?

Jeff

  • I just took a look into the port schematics.
    On the 5x, the pullup/pulldown are disabled when the port is used as output.  If it is input, the output driver is disabled.
    So based on the schematics, what you observe shouldn't happen.

    While PxSEL.y is set, the module controls the direction and therefore the whether the pullups are active or not.
    But then, clearing PxSEL.y while PxDIR.y is also clear (it is a don't care if PxSELy is set) should not affect the pullups.

    You don't write which port you use. On p3, things are rather simple, but on P4, the port mapping controller does additional work (and perhaps confusion).

    Strange is, that this worked with previous revisions.

    I too suspect that late revision changes have changed more than expected, as some problems with crystals seem to be related to a new chip revision too on several devices.

  • JMG,

    Thanks for looking at this.

    This morning I have discovered that one of the slave SPI devices has an _undocumented_ bus keeper on MISO @ 35K ohms.  Whenever the MSP430 pull-down "fights" against the bus keeper in the SPI slave device, the voltage on MISO goes to Vcc/2.  It is the digital input gate inside the MSP430 on MISO that is burning the 4mA in parasitic current.

    So the MSP430 is exonerated in this problem.  And a certain SPI flash manufacturer which shall remain nameless is most definitely on the hook.  Their "drop-in" replacement part most certainly is not.

    As far as MSP430 is concerned, it appears to be OK to use the integrated pull-up/pull-down resistor on the MISO pin in MSP430.

    Jeff

  • Jeff Tenney said:
    This morning I have discovered that one of the slave SPI devices has an _undocumented_ bus keeper on MISO @ 35K ohms

    That's very strange. No slave should have anything on MISO if it isn't chip selected. It shiould go high-impedance.

    Jeff Tenney said:
    Whenever the MSP430 pull-down "fights" against the bus keeper in the SPI slave device, the voltage on MISO goes to Vcc/2.

    Since the MSPs pullups are in the same range, it rather looks like a pullup resistor than a bus keeper. So pullup and pulldown result in VCC/2. And indeed, CMOS inputs don't like input voltages around VCC/2. I was thinking of this myself, but I didn't expect this internal cross current to be that large, so I didn't mention it. I expected a few 100µA at max (which is large compared to the normally 50nA max). But 4mA is not large, that's extremely huge.

    Jeff Tenney said:
    So the MSP430 is exonerated in this problem. 

    Not entirely. The input circuit shouldn't exhibit such a large cross current. Looks like someone has optimized a current-limiter away. (there is no reason why an iput gate can draw such a high operating current at all.

    Jeff Tenney said:
    As far as MSP430 is concerned, it appears to be OK to use the integrated pull-up/pull-down resistor on the MISO pin in MSP430.

    Good you checked this again.

    However, on many 5x famil MSPs, you cannot use the internal pullups for I2C operation since the pullups are disabled when the pin is configured as output - even if it is an OC output.

  • Jens-Michael Gross said:
    But 4mA is not large, that's extremely huge.

    Ah yes, you made me realize that yet another digital input buffer would be looking at Vcc/2, which is the digital input gate inside the SPI flash device on MISO.  Why would the slave have a digital input gate on MISO?  To run the _undocumented_ bus keeper of course!

    I just put Vcc/2 onto MISO with the SPI flash device removed, and the current went up by only 75uA.  That's more like it.

    Jeff

  • Hi everyone,

    I have similar problem with msp430f5510. I can't pull up P4.0 -> P4.3, although other pins work properly. The voltage on these pins is about Vcc/2. I also clear P4SEL.

    Pull down works fine.

    How can I pull them up. Can anyone give my some help!

    Thank you.

**Attention** This is a public forum