SLAU533D September   2013  – April 2017

 

  1.   MSP430F5529 LaunchPad™ Development Kit (MSP‑EXP430F5529LP)
    1.     Trademarks
    2. 1 Getting Started
      1. 1.1 Key Features
      2. 1.2 Kit Contents
      3. 1.3 Out-of-Box Experience
        1. 1.3.1 Step 1: Install a Software Development Platform
        2. 1.3.2 Step 2: Connect the Hardware
        3. 1.3.3 Step 3: Verify the storage volume has been loaded
        4. 1.3.4 Step 4: Open a text editor, and press the buttons
        5. 1.3.5 Step 5: Customize the strings
    3. 2 Hardware
      1. 2.1 Block Diagram
      2. 2.2 Hardware Features
        1. 2.2.1 MSP430F5529
        2. 2.2.2 eZ-FET lite Onboard Emulator
        3. 2.2.3 Integrated Full-Speed USB Hub
        4. 2.2.4 Power
        5. 2.2.5 Clocking
        6. 2.2.6 Application (or "Backchannel") UART
        7. 2.2.7 Emulator and Target Isolation Jumper Block
        8. 2.2.8 Isolation Jumper Block: 3.3-V and 5-V Jumpers
        9. 2.2.9 Isolation Jumper Block: Emulator Connection and Application UART
      3. 2.3 Measure Current Draw of MSP430 MCU
      4. 2.4 Using an External Power Source
        1. 2.4.1 External 3.3-V Power Source
        2. 2.4.2 External 5-V Power Source Without USB Connection
        3. 2.4.3 External 5-V Power Source With USB Connection
      5. 2.5 Using the eZ-FET lite Emulator With a Different Target
      6. 2.6 USB BSL Button
      7. 2.7 BoosterPack Plug-in Module Pinout
      8. 2.8 Design Files
      9. 2.9 Hardware Change Log
    4. 3 Software Examples
      1. 3.1 MSP430 Software Libraries: driverlib and the USB API
      2. 3.2 Viewing the Code
        1. 3.2.1 CCS
        2. 3.2.2 IAR
      3. 3.3 Example Project Software Organization
      4. 3.4 USB Configuration Files
      5. 3.5 Out-of-Box Experience: emulStorageKeyboard
        1. 3.5.1  Flowchart
        2. 3.5.2  Pre-Initialization
        3. 3.5.3  Initialization
          1. 3.5.3.1 Configuring the Keyboard
          2. 3.5.3.2 Configuring the MSC Interface
        4. 3.5.4  Handling SCSI Commands
        5. 3.5.5  LPM0 Entry
        6. 3.5.6  LPM0 Exit
        7. 3.5.7  Emulated Storage Volume
        8. 3.5.8  Sending Data as a USB Keyboard
        9. 3.5.9  Properly Handling USB Unplug Events
        10. 3.5.10 Non-Maskable Interrupt (NMI) Vector
      6. 3.6 Example: simpleUsbBackchannel
        1. 3.6.1 What It Does
        2. 3.6.2 Installing the CDC Interface
        3. 3.6.3 Operating the Example
        4. 3.6.4 Backchannel UART Library: bcUart.c, bcUart.h
        5. 3.6.5 Code Description: Initialization
          1. 3.6.5.1 Stopping the Watchdog
          2. 3.6.5.2 Configuring VCORE
          3. 3.6.5.3 Configuring Clocks
          4. 3.6.5.4 Configuring Ports
          5. 3.6.5.5 Initializing the Backchannel UART
          6. 3.6.5.6 Configuring USB
        6. 3.6.6 Code Description: Main Loop
        7. 3.6.7 Modifying to Use an HID-Datapipe Interface
      7. 3.7 Starting Device Manager
    5. 4 Additional Resources
      1. 4.1 LaunchPad Development Kit Websites
      2. 4.2 Information on the MSP430F5529
      3. 4.3 Download CCS, IAR, mspgcc, or Energia
      4. 4.4 USB Developers Package
      5. 4.5 MSP430Ware and TI Resource Explorer
      6. 4.6 F5529 Code Examples
      7. 4.7 MSP430 Application Notes
      8. 4.8 TI E2E Community
      9. 4.9 Community at Large
    6. 5 FAQs
    7. 6 Schematics
  2.   Revision History

3.5.9 Properly Handling USB Unplug Events

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 development kit 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.