Instructions

User Experience Software www.ti.com
The application must also tell the USB API about the mass storage volume's media; for example, how big
it is, if it is write protected, and if it is been changed recently (if removable). It does this with
USBMSC_updateMediaInfo().
3.5.4 Handling SCSI Commands
The first item in the main loop is a call to USBMSC_poll().
__disable_interrupt();
if ((USBMSC_poll() == kUSBMSC_okToSleep) && !charLeftToSend &&
!bButton1Pressed && !bButton2Pressed)
{
__bis_SR_register(LPM0_bits + GIE);
}
__enable_interrupt();
Notice all of the code surrounding USBMSC_poll(); this is discussed in Section 3.5.5.
Every USB application with an MSC interface must call this function regularly to check for any SCSI
commands received from the host. The USB MSC interface is essentially a carrier for the same SCSI
commands used with many non-USB storage devices that are commonly used with computers. In other
words, the interface is essentially "SCSI-over-USB".
USBMSC_poll() automatically handles all SCSI commands except READ and WRITE. These two require
media access. The developer might choose among a wide variety of media types, and there are many
different file system "middleware" offerings on the market. To preserve these options for the developer, the
MSC API lets the application access the media. mscProcessBuffer() is the function that serves this
function for the software demo; it receives a block buffer from the API and exchanges data between this
buffer and the media. (See Section 3.5.7 for more information.)
Most MSC applications need this exact same block within the main loop, except that the checking of the
charLeftToSend and button-pressed flags are specific to this demo application.
3.5.5 LPM0 Entry
Developing low-power applications is not just about finding the MCU with the lowest-current low-power
modes, although that is an important step. The software also must be written to effectively control the
circuitry and make good use of the low-power modes that are available.
In an application based on a main loop, one way to do this is to have a single location in the loop where a
low-power mode is conditionally entered. Various events can wake it from this sleep and allow the main
loop to resume execution, check flags, and handle any waiting events, and then eventually loop back and
sleep again.
The primary low-power modes are for MSP430 MCUs are LPM0, LPM3, and LPM4 (see Table 9 for a
brief description of these modes). Lower numbers represent "lighter" sleep, while higher numbers
generally mean "heavier" sleep. When the MCU is not in an LPM mode, it is considered to be in "active
mode", which means that all clocks are enabled and the CPU is executing code. (See the MSP430 family
user's guides for complete descriptions of these modes.)
The developer's choice of low-power mode is based on what functionality the MCU needs to keep alive
while sleeping. In the case of USB, the MSP430 can enter LPM0 while the USB connection is active (not
suspended by the USB host), but this is the deepest possible sleep state. When suspended, it can go into
LPM3, which is significantly lower power than LPM0.
With this in mind, refer back to the flowchart in Figure 28. The main loop begins by trying to enter LPM0,
but to do so it evaluates several conditions: the return value of USBMSC_poll(), the number of characters
waiting to be typed to the host, and whether a LaunchPad pushbutton has been pressed. This code was
shown in the previous section.
If USBMSC_poll() returns kUSBMSC_processbuffer, it means the API is waiting for the application to
finish the READ or WRITE operation, and thus it is important to skip LPM0 and proceed to
mscProcessBuffer().
36
MSP430F5529 LaunchPad™ Development Tool (MSP ‑ EXP430F5529LP) SLAU533A–September 2013–Revised January 2014
Submit Documentation Feedback
Copyright © 2013–2014, Texas Instruments Incorporated