tl;dr: the recommended common configuration for pins for low-power mode applies only to unconnected pins. For unused but connected pins, it might be the wrong approach.
As requested:
While doing power tests with the EXP430FR5969 LaunchPad I noticed an anomaly related to the RX jumper in block J13 connecting the XSP430FR5969 to the emulator:
In the application I was working with, I was using EUSCI_A0 as a back-channel UART to display the voltage being presented by the supercap, as collected once per minute.
Experience with earlier MSP430s suggested that in many cases leaving a peripheral enabled forces the clocks the peripheral depends on to remain active, even when supposedly entering LPM levels that would normally turn them off. To cut down on power I wanted to turn off EUSCI_A0 prior to entering LPM so the clock request wouldn't override my intent.
BSP430's serial abstraction provides three levels of "off" for peripherals: iBSP430serialSetReset_rh() simply controls the software reset bit, leaving the GPIOs in their peripheral configuration. iBSP430serialSetHold_rh() goes further, deconfiguring the GPIOs and putting them into the default low-power mode (output low). Both of these can be reversed by re-invoking the function with an enable flag. iBSP430serialClose() deconfigures the peripheral and the pins it depends on and forgets what the configuration was.
I started with "reset" (disable the peripheral, leave the GPIOs configured in the UART function). For power evaluation on the EXP430FR5969 one's supposed to disconnect the eZFET side of the board from the MSP430 side by removing the jumpers on J13. There are eight individual jumpers on that header, and it's a real PITA to pull them off, chase down the ones that flew across the room, put them all back on to reprogram, etc.
For my application, I wanted TX to remain connected so I could see the output each time the thing woke up. Serendipitously, I discovered that I could achieve the nominal 400nA LPM3.5 current (actually, I was getting 250nA) by leaving RTS and CTS off all the time, and only removing the Vin jumper as I went between capacitor-power testing and reprogramming.
Much simpler. This lasted until I was happy with everything, then decided I should be using the "hold" variant because clearly putting the GPIOs into low-power mode might reduce power even more, no?
No. All of a sudden I couldn't get anything below 4uA in LPM3.5 any more.
Fussing about ensued, with the eventual discovery above: something about being configured in GPIO mode made it necessary to remove the RX jumper, while leaving RX shorted is fine if the pin is in its UART configuration.
I'm sure those who are EEs can explain exactly what's happening, and why, and never (well, hardly ever) make such mistakes.
The takeaway, though, is that when the user's guide recommends input/pulldown/pullup or output low as the default configuration for LPM for "unused pins", they really mean unconnected pins. Which is different, especially on evaluation/experimenter boards where there are all kinds of features that aren't being used for a particular application. For the EXP430FR5969, the recommended configuration happens to work for most of the pins that cross the J13 header, but not for RX (and CTS; RTS is fine), presumably because of what they're connected to on the ezFET side of the board.
Beware: It'll also hold for pins on boards where there isn't a jumper you can remove for power testing.
So: As usual, the basic rule doesn't always apply. Make assumptions, fine; but test them, and if something doesn't make sense, take the time to analyze it and figure out what's going wrong.
And explain it all here on the forums so others can benefit from your experiences or correct your misunderstandings. (I'm not going to get any real work done the rest of this week, am I? Didn't think so....)
As requested:
While doing power tests with the EXP430FR5969 LaunchPad I noticed an anomaly related to the RX jumper in block J13 connecting the XSP430FR5969 to the emulator:
- If P2SEL1.1 is clear (P1.2 is a GPIO) and J13.RX is shorted, current draw is high in LPM3.5.
- If P2SEL1.1 is clear (P1.2 is a GPIO) and J13.RX is open, current draw is low in LPM3.5.
- If P2SEL1.1 is set (P1.2 is EUSCI_A0.RX) and J13.RX is shorted, current draw is low in LPM3.5.
- If P2SEL1.1 is set (P1.2 is EUSCI_A0.RX) and J13.RX is open, current draw is high in LPM3.5.
In the application I was working with, I was using EUSCI_A0 as a back-channel UART to display the voltage being presented by the supercap, as collected once per minute.
Experience with earlier MSP430s suggested that in many cases leaving a peripheral enabled forces the clocks the peripheral depends on to remain active, even when supposedly entering LPM levels that would normally turn them off. To cut down on power I wanted to turn off EUSCI_A0 prior to entering LPM so the clock request wouldn't override my intent.
BSP430's serial abstraction provides three levels of "off" for peripherals: iBSP430serialSetReset_rh() simply controls the software reset bit, leaving the GPIOs in their peripheral configuration. iBSP430serialSetHold_rh() goes further, deconfiguring the GPIOs and putting them into the default low-power mode (output low). Both of these can be reversed by re-invoking the function with an enable flag. iBSP430serialClose() deconfigures the peripheral and the pins it depends on and forgets what the configuration was.
I started with "reset" (disable the peripheral, leave the GPIOs configured in the UART function). For power evaluation on the EXP430FR5969 one's supposed to disconnect the eZFET side of the board from the MSP430 side by removing the jumpers on J13. There are eight individual jumpers on that header, and it's a real PITA to pull them off, chase down the ones that flew across the room, put them all back on to reprogram, etc.
For my application, I wanted TX to remain connected so I could see the output each time the thing woke up. Serendipitously, I discovered that I could achieve the nominal 400nA LPM3.5 current (actually, I was getting 250nA) by leaving RTS and CTS off all the time, and only removing the Vin jumper as I went between capacitor-power testing and reprogramming.
Much simpler. This lasted until I was happy with everything, then decided I should be using the "hold" variant because clearly putting the GPIOs into low-power mode might reduce power even more, no?
No. All of a sudden I couldn't get anything below 4uA in LPM3.5 any more.
Fussing about ensued, with the eventual discovery above: something about being configured in GPIO mode made it necessary to remove the RX jumper, while leaving RX shorted is fine if the pin is in its UART configuration.
I'm sure those who are EEs can explain exactly what's happening, and why, and never (well, hardly ever) make such mistakes.
The takeaway, though, is that when the user's guide recommends input/pulldown/pullup or output low as the default configuration for LPM for "unused pins", they really mean unconnected pins. Which is different, especially on evaluation/experimenter boards where there are all kinds of features that aren't being used for a particular application. For the EXP430FR5969, the recommended configuration happens to work for most of the pins that cross the J13 header, but not for RX (and CTS; RTS is fine), presumably because of what they're connected to on the ezFET side of the board.
Beware: It'll also hold for pins on boards where there isn't a jumper you can remove for power testing.
So: As usual, the basic rule doesn't always apply. Make assumptions, fine; but test them, and if something doesn't make sense, take the time to analyze it and figure out what's going wrong.
And explain it all here on the forums so others can benefit from your experiences or correct your misunderstandings. (I'm not going to get any real work done the rest of this week, am I? Didn't think so....)