Instructions

User Experience Software www.ti.com
USB events are like software callbacks, functions called by the USB interrupt service routine (ISR) that the
application can choose to service. These handlers are in the file usbEventHandling.c. If the event handler
returns TRUE, the CPU remains awake after the USB ISR returns; this causes execution to resume from
the point of LPM0 entry, if it had been sleeping there. (If it had not been sleeping, then the resumption has
no effect.)
The last event that can wake the CPU out of LPM0 is a pushbutton press. This generates an I/O port
interrupt, and the port ISR in hal.c is executed. It includes an intrinsic function
__bic_SR_register_on_exit(LPM3_bits); this causes execution to resume from the point of LPM0 entry, if it
had been sleeping there. Again, if it had not been sleeping, this resumption has no effect.
3.5.7 Emulated Storage Volume
mscProcessBuffer() is the first function to run after waking from LPM0. It checks the "operation" field of the
RWbuf_info structure to see if the USB API is waiting for the application to handle any READ or WRITE
buffer operations from the USB host.
If a READ or WRITE is pending, mscProcessBuffer accesses the media to perform the read or write. It
does this by issuing low-level commands to the FatFs file system library, disk_read() and disk_write().
The block of code within mscProcessBuffer() for performing READs is:
while (RWbuf_info->operation == kUSBMSC_READ)
{
RWbuf_info->returnCode = disk_read(0,
RWbuf_info->bufferAddr,
RWbuf_info->lba,
RWbuf_info->lbCount); // Fetch a block from the medium
USBMSC_bufferProcessed(); // Close the buffer operation
}
In a more typical mass storage application, the media would probably be an SD-card or external SPI flash.
In this application, the media is located inside the MSP430 internal flash memory. This is only
approximately 60KB, but it is big enough for what this demo needs, and saves the cost and complexity of
external media.
FatFs is commonly used to interface with FAT-formatted memory cards, but for this example it is been
customized for internal MSP430 flash. Most of this was done in disk_read() and disk_write().
Whereas the high-level FatFs calls ask FatFs to open or read files, and leave it to FatFs to parse the
volume and locate the files itself, the low-level calls bypass this, asking FatFs to read/write specific
locations in the volume. These locations are measured in blocks or sectors. The address of a block is
called a logical block address, or LBA, which is a parameter passed to disk_read().
The demo application implements the volume as an array called storageVol[]. The C-code contents of
storageVol[] contain the files that were seen in Step 3 of Section 1.3. storageVol[] occupies all of the
F5529's upper on-chip flash memory, from address 0x10000 to the end of the map, 0x243FF. To ensure
the linker does not place any code or other data there, a special linker segment has been set up:
MYDRIVE. This segment is defined in the auxiliary linker file \USB_app\F5529LP_UE.cmd.
storageVolume.c then contains code to locate storageVol[] there.
The volume within storageVol[] is formatted as FAT. It was generated using a procedure that is described
in the comments in storageVol.c. You can use this same procedure to create your own storage volumes
represented in C code, with your own file/directory sets.
If you are interested in using FatFs for SD cards, download the USB Developers Package and look in the
USB examples for MSC interfaces. One of the examples is a USB SD-card reader, written to run on the
F5529 Experimenter's Board (MSP-EXP430F5529) which has an SD-card socket on it. This example has
a version of FatFs set up for this purpose.
3.5.8 Sending Data as a USB Keyboard
In USB, keyboards are implemented as Human Interface Device (HID) interfaces. Within the USB
descriptors reported to the host during enumeration, the application declares itself to contain a keyboard
HID interface. It then sends specially formatted HID reports to the host, to tell it about key presses. While
no key presses occur, no reports are sent.
38
MSP430F5529 LaunchPad™ Development Tool (MSP ‑ EXP430F5529LP) SLAU533A–September 2013–Revised January 2014
Submit Documentation Feedback
Copyright © 2013–2014, Texas Instruments Incorporated