Texas Instruments MSP-EXP430F5529LP Manuale Utente

In USB, it is important to consider that the bus may suddenly become unavailable. For example, the USB
cable can be removed by the user at any time. If the developer does not keep this in mind, it is easy to
write code that can hang up indefinitely when it happens.

For example, suppose the bUsbSendComplete flag had been polled until it was set to TRUE. If the cable
was then removed between the call to USBHID_sendReport() and the time the host fetches the report, the
flag would never become TRUE, and execution would freeze. Granted, with a 1-ms polling interval, this is
a very small window. But if this code went into a product, with thousands of users in the field, eventually it
would occur. (The default LaunchPad configuration is bus-powered, losing power when detached from the
host. So this error won't occur unless external power is used. However, the code was written this way to
show good USB coding practices.)

Another thing that can go wrong is if the host becomes unresponsive. This is more problematic for MSC
and CDC interfaces than for HID interfaces, because the former use USB bulk transfers, which are more
subject to host and bus conditions. In contrast, HID is guaranteed to be polled at the polling interval, as
long as the host is functioning properly. But even so, if the host crashes, it is undesirable for the USB
device to hang. Therefore, good coding practice requires considering what happens if the
USBHID_handleSendCompleted() event never occurs, or if USBHID_sendReport() returns
kUSBHID_intfBusyError.

The application deals with these problems by never depending on the bUsbSendComplete flag for
execution fluidity. Whatever USBHID_sendReport() returns, the next line of code is always
USB_connectionState(). So if the cable has been detached, execution shifts to the switch() case that
shuts down all string sending and enters LPM3. If instead USB remains connected, but the host has
crashed, then the application functions as it always had, with fluid execution; the only difference is that
USBHID_sendReport() always returns kUSBHID_intfBusyError and no characters are actually sent.

The MSP430 contains one vector that cannot be disabled by the general interrupt enable (GIE) bit: the
NMI vector. Several different events are directed into the NMI vector, most of which involve critical
functions. Oscillator failure is one example.

There is one NMI unique to USB operation: the "bus error", which is indicated when the SYSUNIV
interrupt vector register contains the value SYSUNIV_BUSIFG. This involves the fact that the MSP430
USB module shares a block of RAM with the CPU, called "USB RAM". When the host suspends the USB
module, it becomes clocked by a slow clock. If the CPU then tries to access USB RAM, the difference in
clock speeds between this slow clock and the MCU clock creates a conflict, and recovery from the error is
not possible without shutting down the USB module.

Fortunately this event is completely within control of software, by not accessing USB RAM during
suspend. The USB API is written to not do this, and most applications do not have a reason to access
USB RAM. Therefore, this error should never occur. But in the event that it does, the NMI is provided, and
code is provided to handle the failure.

The simpleUsbBackchannel example runs on Windows and Linux PCs. However, it does not run on Macs,
because the OS X does not support composite CDC devices. This means that OS X does not support the
eZ-FET lite emulator or its backchannel UART.

The simpleUsbBackchannel example receives data over the backchannel UART and sends it back to the
host PC over USB (see

). By default, the USB connection uses a CDC interface, which results in

a virtual COM port on the host. Thus both sides of the communication loop terminate in virtual COM ports
on the host. Through these COM ports, two instances of a terminal application can exchange data.

40

‑

SLAU533A – September 2013 – Revised January 2014

Copyright © 2013–2014, Texas Instruments Incorporated