USCI UART mode for LPM3: current consumption

First of all, have you configurated the pins in LPM mode?, is to say, the pins must be set by the proper way. It is better explained in the user guide, 1.6, connection on unused pins. All the pins, that you do not use, have to be configurated as ouput direction and low value for example.

About LPM, the only LPM that disable all clocks is LPM4, but if there is some peripheral module that needs clock, the clock will run, unless you have modified the clock request bit in UCSCTL8. So if you need clock, it is correct to use LPM3, since LPM4 with clock enable is the same that LPM3. Moreover, you have to take care with the clock source you use, 1Mhz clock consumes more than a 32 kHz clock, and this one consumes more than a 1 kHz clock.

I hope that it can help you or give you some new idea at least.

Hello,

everything works just fine, the problem is not the normal mode or the LPM3, it really must have something to do with P3SEL = 0x30;

And another strange thing is the fact that my additional 6 mA I cannot switch back by disabling the PSEL again.

I am currently looking at my code and playing around, but this part htat I cannot switch the current back by diabling what I did with the register settings really confuses me, normally I can always toggle the current consumption by toggling the involved pins in their functions, this time it seems just like a schmitt trigger :(

Thanks for your effort.

Ok my fault, I just toggelt wrong PSEL bits, current drawn is basically dependent from the UART_A0 module I configured,  but I am still of the opinion that it should not be that excessive 7 mA in addition.

seb said:

Ok my fault, I just toggelt wrong PSEL bits, current drawn is basically dependent from the UART_A0 module I configured,  but I am still of the opinion that it should not be that excessive 7 mA in addition.

This amoutn of current is definitely not consumed by the UART itself (which would be independent of the PxSEL bits anyway). Tho the reason is, why does the port pin logic draw that much.  port pins are push/pull (except in I2C mode). When you set the PxSEL bits for the UART pins, you switch them from GPIO input to UART output. And output tries to maintain the output voltage actively, which is high (VCC) on idle.
Now if oyu have a load on the TX line that is 470Ohm, then the port pin has to drive 7mA into this load to maintain a high level on that pin (assuming VCC=3V).
This may happen if you have the MSP powered, but the peripheral on the other side of the TX lien isn't. Or you have a pullup on the line but the pullup goes to unpowered supply (then it turns into a pulldown to).

Of course flaws in the PCB are another possible reason.

Yep you are right. I am indeed trying to set the PSEL bits for UART while not powering the attached TUSB3410 device, which is only powered once the usb is physically plugged in.

My workaround ist right now is to enable only the PSEL when i detect the usb plugged in status, this seems to work fine.

But then as I said I cannot wake the device up over USB, because I wont detect any signals on that line.

That is a little minus, but we can work this out by describing it in the manual I guess.

seb said:

But then as I said I cannot wake the device up over USB, because I wont detect any signals on that line.

Well, you can route VUSB to an MSP pin (with a voltage divider) and detect the rising edge on a port interrupt. So the MSP will wake when the device is plugged-in and can go to sleep when it is removed from the USB line.

Exactly that I would do if I had known this 1 year ago and would have thought this into my PCB desing :) unfortunatly I didnt, and know i have to work without that feature, untill we do a new design probably in a year, perhaps later.

But thanks anyway, as always.

Hi seb,

You should be able to wake up the MSP430 from LPM0 through LPM4 as soon as it receives a UART request if you enable the USCI RX interrupt. The USCI module will remain unclocked while idle, and will automatically start its clock source once it detects the START bit edge of the UART packet and will wake the CPU.

So you may wish to leave the MSP430 in LPM4 until the user initiates serial communication through the TUSB3410.

How are you storing the VID/PID for the TUSB3410? If you are emulating an EEPROM with the MSP430 through I2C, that's another route to wake up the CPU once the USB is connected (the TUSB3410 searches for EEPROM on the I2C bus as soon as it's connected).

Tony

Thanks for those ideas, but I expirienced some really high current drwan when leaving the UART enabled in LPM3 ( around 6 mA ) , and normally I operate with about 3 µA in LPM3. This really is important for our applicatino since its batterie powered.

And for the TUSB I havent quite figured out how this is working, but I have a external FRAM on my PCB to do the EEPROM work via I2C, didnt do it yet though, so I cannot tell how I will use that.

But if you know your USB stuff, perhaps you could gibve me some further advice about the VID and PID stuff. I figured out that I couldnt reprogram those values since You have to buy those unique IDs from usb.org for around 2000 $. Normal? approach would be to use the TUSB and simply use TIs VID and PID, becasue they have a license and it will work out. Of course end goal must be that our device is recognized by the PC as " our device name" and not the generic TUSB3410 COM port, I dont know yet if I can do that without acquiring my own VID PID from usb.org, there you might have some knowledge for me?

Thanks a lot.

Hi seb,

Have you tried to enable only the RX pin? Since the pin is input and thus high-Z, it should consume not much more than leakage and buffer logic. You can then enable TX once the device wakes up from an RX interrupt.

As for VID/PID, TI actually has a VID sharing program where you can license a PID under a special TI VID free of charge for use with TI products. I believe the link is on one of the USB pages. There's also an appnote on the TUSB3410 product page on this topic.

If you read the TUSB3410 manual, it specifically discourages you to just use the default VID/PID in the end product, for a variety of reason, not the least of which is that it violates the USB standard hence you won't get certified or WHQL'd.

Tony