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.

MSP430G2553: Parasitic Current Consumption When Serial Host Disconnected?

Part Number: MSP430G2553
Other Parts Discussed in Thread: ENERGYTRACE

I am having an issue with an embedded design based around the MSP430G2553. The application has the MCU wait in standby for very long periods of time. When it is time for the system to operate, a host controller communicates with the MCU via serial communication. 

I have characterized the system with both EnergyTrace and a Fluke 87V multimeter in series with a coin-cell battery. During standby, I get an average current consumption of ~ 28 uA. This result agrees with the measurement with EnergyTrace.

However, these tests were performed with the host controller connected but inactive. In the actual use case, the host controller will be powered down and the embedded MCU will need to remain active for 4+ weeks. Today I repeated my tests and I powered down the host controller by unplugging it from its USB connection. The current consumption from the coin-cell is now between 1 - 3 mA! This appears to be some parasitic current draw from the coin-cell over the serial communication lines that are connected to the powered down host controller.

I only get the expected 28 uA if I physically remove the serial connection between the MCU and the host controller or if I leave the host controller connected and powered on (like I did during my initial tests). With the current design, the serial communication lines are directly connected between the host controller and the MCU.

Am I missing some best "practice" technique for decoupling the serial communication lines properly?

  • Let me guess, the serial output from the MSP is left high, aka 3.3V or thereabouts.

    If the other end is CMOS it will have ESD clamping diodes on its I/O lines to Vcc and ground. Which means that your serial out is attempting to power the host via a forward biased diode to Vcc. This assumes that both systems still share a ground but an output that is low could have a similar effect via the clamping diode to ground.

  • Yes, the current software design has the embedded MCU "screaming into the void" while it is in standby... 

    Your description makes sense, that is exactly what I am observing. Could I use a blocking diode somewhere?

  • Minor update: it is not simply because the MCU is sending unanswered serial commands during the standby, I think it is the physical connection. 

    I just tested a version of the code that suspends the MCU until it receives an external interrupt (i.e. no serial comms whatsoever). When I power down the host controller, I see the large parasitic current draw from the coin cell. So just having the TX, RX, and GND lines physically connected to the MCU is causing this issue. How can I fix this with hardware?

  • My answer didn't depend on serial activity but assumed the idle state of the TX pin was high which is typical for a UART.

    Make it low (grab control of the pin from the UART) before powering down. I suppose you could put a diode in series so the TX pin can only pull the line down along with a pull up resistor on the host side but that limits your bit rate.

    Of course if you have a pull up resistor on an input it is going to source current to that powered down host as well. But at least you can limit that by your choice of resistor.

  • Alright, so I found a solution but I would love to hear someone's opinion on why it works. I am going to dig into the controller datasheets in a bit to try and see for myself. If I find anything I'll post it here.

    The solution: I added a 1 MΩ resistor in series with the ground connection between the embedded MSP430 MCU and the host controller. The current consumption is now ~31 uA when I power down the host controller. 1 MΩ at 3.0V equates to 3 uA, and 28 uA + 3 uA is 31 uA so this measurement makes sense.

  • Update: this solution was a complete fluke caused by a hidden ground connection I had through my laptop and bench power supply. A 1 MΩ resistor in series with the ground connection makes the UART non functional, as to be expected.

**Attention** This is a public forum