This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

USB controller - LPC2364

I need to write a custom USB controller to communicate with a PC. Over the USB we will perform firmware upgrades, upload new operating parameters, download device performance data, etc. The PC side will use WinUSB mechanism to manage the USB device. I need to implement the USB control using a single interface with 2 bulf transfer endpoints, input and output. Have experimented with the USB CDC device example that came with the Keil toolset. I was thinking of taking that example and modify the descriptors and remove any unneeded logic that implemeted the CDC device and add what I need for my project.

Does this seem like a reasonebly place to start? For example, are the handling of the control endpoint esentially the same regardless of device class type?

Parents
  • Part 1

    "I need to implement the USB control using a single interface with 2 bulf transfer endpoints, input and output."

    Then, mass storage class (MSC) is better for the start point for the modification.

    "LPC2368 / LPC2378 USB Mass Storage Device Example" on KEIL download area
    http://www.keil.com/download/docs/336.asp

    As of the low-level USB firmware, MSC is simpler than CDC, and it is much similar to your target configuration. CDC has two interfaces and an extra interrupt EP. Also many class-specific requests.


    [ Step 0 ]
    First, download above KEIL example for MSC, and run it on your board.
    If it doesn't run, fix it. Maybe the problem is caused by the difference of the hardware connection between the KEIL dev board and your board. As you said you've already run the CDC example on your board. The porting experience is also applied to this MSC example.


    Now modify this MSC code to a vendor specific bulk device.
    The basic modification is applied to descriptor, class-specific request and the endpoint handling.

    [ Descriptor work ]
    usbdesc.c
    a) USB_DeviceDescriptor
    Modify VID/PID (or at least PID)

    const BYTE USB_DeviceDescriptor[] = {
      USB_DEVICE_DESC_SIZE,              /* bLength */
      USB_DEVICE_DESCRIPTOR_TYPE,        /* bDescriptorType */
      WBVAL(0x0110), /* 1.10 */          /* bcdUSB */
      0x00,                              /* bDeviceClass */
      0x00,                              /* bDeviceSubClass */
      0x00,                              /* bDeviceProtocol */
      USB_MAX_PACKET0,                   /* bMaxPacketSize0 */
      WBVAL(0xC251),                     /* idVendor */
      WBVAL(0x1703),                     /* idProduct */
      WBVAL(0x0100), /* 1.00 */          /* bcdDevice */
      0x04,                              /* iManufacturer */
      0x20,                              /* iProduct */
      0x48,                              /* iSerialNumber */
      0x01                               /* bNumConfigurations */
    };
    


    Unique VID/PID prevents driver conflict on your PC.
    To find a unique VID/PID on your PC, open this key on a registry editor (regedit or such).

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB

    You'll find a list of Vid_vvvv&PID_xxxx under this key. These VID/PIDs are registered to your system. (Don't modify these VID/PID directly - it is referred another place on the registry)
    Select a VID/PID which is not registered on this list, for temporary VID/PID of your project.
    Please note, it is not an official one, just for temporary use for the development. When you'll release your device, get an official VID/PID.

    To get a unique VID/PID officially,
    - Some MCU manufacturers distributes free PID under their VID, for sales promotion of their device; Microchip, SiLabs, etc.

    - Some shops sell a range of PID
    VOTI: www.voti.nl/.../catalog.html

    - To register your VID officially to USB IF
    1. Apply membership of the USB IF for annual fee of US$4,000.
    2. Logo licensee for US$2,000 for 2-years term.
    3. Pay one-time fee of US$2,000 to buy a VID

    www.usb.org/.../


    b) USB_ConfigDescriptor
    Modify the interface triad (class, subclass and protocol) to the vendor specific class

    const BYTE USB_ConfigDescriptor[] = {
    ...
    /* Interface 0, Alternate Setting 0, MSC Class */
      USB_INTERFACE_DESC_SIZE,           /* bLength */
      USB_INTERFACE_DESCRIPTOR_TYPE,     /* bDescriptorType */
      0x00,                              /* bInterfaceNumber */
      0x00,                              /* bAlternateSetting */
      0x02,                              /* bNumEndpoints */
      USB_DEVICE_CLASS_STORAGE,          /* bInterfaceClass */     <-- 0xFF (Vendor specific)
      MSC_SUBCLASS_SCSI,                 /* bInterfaceSubClass */  <-- 0x00 (no subclass)
      MSC_PROTOCOL_BULK_ONLY,            /* bInterfaceProtocol */  <-- 0x00 (no protocol)
      0x62,                              /* iInterface */
    ...
    

Reply
  • Part 1

    "I need to implement the USB control using a single interface with 2 bulf transfer endpoints, input and output."

    Then, mass storage class (MSC) is better for the start point for the modification.

    "LPC2368 / LPC2378 USB Mass Storage Device Example" on KEIL download area
    http://www.keil.com/download/docs/336.asp

    As of the low-level USB firmware, MSC is simpler than CDC, and it is much similar to your target configuration. CDC has two interfaces and an extra interrupt EP. Also many class-specific requests.


    [ Step 0 ]
    First, download above KEIL example for MSC, and run it on your board.
    If it doesn't run, fix it. Maybe the problem is caused by the difference of the hardware connection between the KEIL dev board and your board. As you said you've already run the CDC example on your board. The porting experience is also applied to this MSC example.


    Now modify this MSC code to a vendor specific bulk device.
    The basic modification is applied to descriptor, class-specific request and the endpoint handling.

    [ Descriptor work ]
    usbdesc.c
    a) USB_DeviceDescriptor
    Modify VID/PID (or at least PID)

    const BYTE USB_DeviceDescriptor[] = {
      USB_DEVICE_DESC_SIZE,              /* bLength */
      USB_DEVICE_DESCRIPTOR_TYPE,        /* bDescriptorType */
      WBVAL(0x0110), /* 1.10 */          /* bcdUSB */
      0x00,                              /* bDeviceClass */
      0x00,                              /* bDeviceSubClass */
      0x00,                              /* bDeviceProtocol */
      USB_MAX_PACKET0,                   /* bMaxPacketSize0 */
      WBVAL(0xC251),                     /* idVendor */
      WBVAL(0x1703),                     /* idProduct */
      WBVAL(0x0100), /* 1.00 */          /* bcdDevice */
      0x04,                              /* iManufacturer */
      0x20,                              /* iProduct */
      0x48,                              /* iSerialNumber */
      0x01                               /* bNumConfigurations */
    };
    


    Unique VID/PID prevents driver conflict on your PC.
    To find a unique VID/PID on your PC, open this key on a registry editor (regedit or such).

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB

    You'll find a list of Vid_vvvv&PID_xxxx under this key. These VID/PIDs are registered to your system. (Don't modify these VID/PID directly - it is referred another place on the registry)
    Select a VID/PID which is not registered on this list, for temporary VID/PID of your project.
    Please note, it is not an official one, just for temporary use for the development. When you'll release your device, get an official VID/PID.

    To get a unique VID/PID officially,
    - Some MCU manufacturers distributes free PID under their VID, for sales promotion of their device; Microchip, SiLabs, etc.

    - Some shops sell a range of PID
    VOTI: www.voti.nl/.../catalog.html

    - To register your VID officially to USB IF
    1. Apply membership of the USB IF for annual fee of US$4,000.
    2. Logo licensee for US$2,000 for 2-years term.
    3. Pay one-time fee of US$2,000 to buy a VID

    www.usb.org/.../


    b) USB_ConfigDescriptor
    Modify the interface triad (class, subclass and protocol) to the vendor specific class

    const BYTE USB_ConfigDescriptor[] = {
    ...
    /* Interface 0, Alternate Setting 0, MSC Class */
      USB_INTERFACE_DESC_SIZE,           /* bLength */
      USB_INTERFACE_DESCRIPTOR_TYPE,     /* bDescriptorType */
      0x00,                              /* bInterfaceNumber */
      0x00,                              /* bAlternateSetting */
      0x02,                              /* bNumEndpoints */
      USB_DEVICE_CLASS_STORAGE,          /* bInterfaceClass */     <-- 0xFF (Vendor specific)
      MSC_SUBCLASS_SCSI,                 /* bInterfaceSubClass */  <-- 0x00 (no subclass)
      MSC_PROTOCOL_BULK_ONLY,            /* bInterfaceProtocol */  <-- 0x00 (no protocol)
      0x62,                              /* iInterface */
    ...
    

Children
  • Part 2

    [ class-specific request ]
    MSC implements Bulk_Only_Mass_Storage_Reset and Get_Max_LUN class specific requests. As these requests are not used for your project, comment them out.
    Instead, implement a vendor specific request handler.

    usbcore.c
    void USB_EndPoint0 (DWORD event) {
    ...
    #if USB_MSC
    /*
    //    MSC class specific requests - comment them out
    
                  if (SetupPacket.wIndex.WB.L == USB_MSC_IF_NUM) {
                    switch (SetupPacket.bRequest) {
                      case MSC_REQUEST_RESET:
                        if (MSC_Reset()) {
                          USB_StatusInStage();
                          goto class_ok;
                        }
                        break;
                      case MSC_REQUEST_GET_MAX_LUN:
                        if (MSC_GetMaxLUN()) {
                          EP0Data.pData = EP0Buf;
                          USB_DataInStage();
                          goto class_ok;
                        }
                        break;
                    }
                  }
    */
    #endif  /* USB_MSC */
    ...
        //
        // implement a vendor request handler
        //
            case REQUEST_VENDOR:
              if ( vendor_request_handler() )
                goto stall_i;
              break;
    

    This is a skeleton of vendor request handler.

    __inline BOOL vendor_request_handler (void)
    {
      switch (SetupPacket.bmRequestType.BM.Recipient) {
        case REQUEST_TO_DEVICE:
            switch (SetupPacket.bRequest) {    // parse the requests
                case xxxx:
                  //
                  // Do the request here
                  // Parameters are retrieved in SetupPacket.wValue and SetupPacket.wIndex
                  //
                  // just when the request needs reply (IN request)
                    EP0Data.pData = ptr_to_your_data_buffer;
                  break;
    
                default:
                  return (FALSE);
            }
        default:
          return (FALSE);
      }
    
      switch (SetupPacket.bmRequestType.BM.Dir) {
        case REQUEST_HOST_TO_DEVICE:
          USB_StatusInStage();
          break;
        case REQUEST_DEVICE_TO_HOST:
          USB_DataInStage();
          break;
        default:
          return (FALSE);
      }
      return (TRUE);
    }
    


    [ endpoint handling ]
    The MSC example uses EP2 IN and OUT.
    This modification shows simple loop-back from the bulk OUT EP to the bulk IN EP (less than 64 bytes).

    usbuser.c
    void USB_EndPoint2 (DWORD event) {
      switch (event) {
        case USB_EVT_OUT:
    //
    //      MSC_BulkOut();  // comment out
    //
          BulkLen = USB_ReadEP(MSC_EP_OUT, BulkBuf);
          USB_WriteEP(MSC_EP_IN, BulkBuf, BulkLen);
          break;
        case USB_EVT_IN:
    //
    //      MSC_BulkIn();   // comment out
    //
          break;
      }
    }
    


    [ Host PC side ]
    a) INF file of WinUSB
    Copy the example of WinUSB INF file and open it using a text editor.
    Find "USB\VID_vvvv&PID_pppp" pattern on the file.
    Replace the VID/PID to the above one chosen for the development.
    When the device is plugged in to your PC, select this modified INF for the installation.

    b) Host application for WinUSB

    WinUSB host app example by J.Axelson
    http://www.lvr.com/winusb.htm


    Tsuneo

  • bug fixes for above snippets:

    The dispatcher of vendor request handler - missed "!"

        //
        // implement a vendor request handler
        //
            case REQUEST_VENDOR:
              if ( ! vendor_request_handler() )
                goto stall_i;
              break;
    


    The body of vendor_request_handler - added return length handling

    __inline BOOL vendor_request_handler (void)
    {
      DWORD len;
      switch (SetupPacket.bmRequestType.BM.Recipient) {
        case REQUEST_TO_DEVICE:
            switch (SetupPacket.bRequest) {    // parse the requests
                case xxxx:
                  //
                  // Do the request here
                  // Parameters are retrieved in SetupPacket.wValue and SetupPacket.wIndex
                  //
    
                  // just when the request needs reply (IN request)
                    len = number_of_bytes_in_your_data_buffer;
                    EP0Data.pData = ptr_to_your_data_buffer;
                  break;
    
                default:
                  return (FALSE);
            }
        default:
          return (FALSE);
      }
    
      switch (SetupPacket.bmRequestType.BM.Dir) {
        case REQUEST_HOST_TO_DEVICE:
          USB_StatusInStage();
          break;
        case REQUEST_DEVICE_TO_HOST:
          if (EP0Data.Count > len) {
            EP0Data.Count = len;
          }
          USB_DataInStage();
          break;
        default:
          return (FALSE);
      }
      return (TRUE);
    }
    

    Tsuneo

  • Thank you for the excellent information.

    In function USB_EndPoint0 (), you mention to add vendor_request_handler() to respond to REQUEST_VENDOR.

    What sort of vendor specic endpoint0 requests would this be? Is this all implementation defined or will these be standard USB protocol handling?

    Our design proposal was to send all vendor specific commands and data via the 2 bulk endpoints. I thought that endpoint0 was common regardless of what type of usb class device being implemented.

  • Also, I notice on the USB mass storage device example that it uses a single endpoint number (2 in this case) to support both IN and OUT endpoint adresses.

    In general, what is the strategy for using one enpoint number for both IN and OUT versus 2 endpoint numbers, one for IN and the other for OUT?

  • Tsuneo,

    I have worked through most of the steps in your suggestion and now ready to test with a PC with WinUSB application. It appears that I need to install WDK (windows Device Kit) for the files I need for WinUSB (on my laptop which is running XP). The Microsoft sites are very confusing on what I need to install, would you happen to have some advice on the exact package I need to install?

    Thanks again for you help.

  • "What sort of vendor specic endpoint0 requests would this be? Is this all implementation defined or will these be standard USB protocol handling?"

    The implementation of the vendor request handler is optional. It was shown because you've asked as follows,
    "are the handling of the control endpoint esentially the same regardless of device class type?"


    "Our design proposal was to send all vendor specific commands and data via the 2 bulk endpoints."

    When each pipe is assigned for single purpose, the firmware becomes much simpler. Suppose that you are working on a USB data acquisition project.
    You may assign a bulk IN EP for the data stream, an interrupt OUT EP for command, and an interrupt IN EP for status. WinUSB supports any number of IN and OUT endpoints (EPs) in a single interface. Also, you can mix interrupt and bulk EPs together.

    The handling of control transfer including vendor request is heavier than that of bulk and interrupt EPs. Then, when bulk or interrupt EPs are available, assign these pipes instead of vendor request.


    "In general, what is the strategy for using one enpoint number for both IN and OUT versus 2 endpoint numbers, one for IN and the other for OUT?"

    In USB common sense, IN and OUT EPs are completely independent even if it shares the same endpoint address, except for the default EPs which are tied by the protocol of the control transfer. Just the KEIL examples tie them together uselessly. If they split the handler for the IN and OUT EPs, the examples get a little more performance.


    "It appears that I need to install WDK (windows Device Kit) for the files I need for WinUSB (on my laptop which is running XP)."

    Vista has built-in WinUSB device driver, but XP doesn't.
    Visit to this MS WHDC page.

    "How to Use WinUSB to Communicate with a USB Device" from MS WHDC
    www.microsoft.com/.../winusb_howto.mspx

    On the right "download" column of this page, you'll see this link.
    Download this document for WinUSB instructions.

    "WinUsb_howto.docx"
    download.microsoft.com/.../WinUsb_HowTo.docx

    Find this section on the document. It describes about the installation package, and an example of INF file.
    "How to Install WinUsb.sys as a Function Driver"

    Tsuneo

  • Thanks you have been very helpful. But now I am stuck again, maybe you know of this issue too. I have used the example I have used the sample INF files you suggested but the device initialization fails when it hits the KMDF co installer section -

    [CoInstallers_CopyFiles]
    WinUSBCoInstaller.dll
    WdfCoInstaller01005.dll

    I do not have the WdfCoInstaller01005.dll on my system nor can I seem where to find it. Any ideas?

  • As the instruction says, the file name, WdfCoInstaller01005.dll, alters in version to version, at the numbering postfix. Replace the file name to that of the WDK downloaded.

    Tsueno

  • Actually it turns out the version of WDK I donwloaded temporarily did not include that particular co-installer,some sort of bug. You have to separately download that co-installer, which I did.

    Thanks again for all your help.

  • Tsueno,

    Some weeks ago I completed this USB project but just noticed that Windows is picky on which physical USB port I plug my device into. If I plug it into a port that I did not originally install the driver Windows does not recognize it ans prompts to install a driver. I did not think physical port mattered.

    Paul

  • "If I plug it into a port that I did not originally install the driver Windows does not recognize it ans prompts to install a driver."

    It sound like a typical symptom of no serial number.
    Does your device have serial number?

    Windows identify each device with serial number of the device, other than VID/PID. When no serial number is supplied, Windows identify your device by the port. Then, you'll see New Device dialog when the device is connected to other port.

    Tsuneo

  • Tsuneo,
    do you know any application with code that would let me click on a button and send data from the host to the device via bulk? If so, would you care to share?
    thanks!

  • I use LPC2378 in MCB2300 with usbmem demo.

    When I change the bulk endpoint from 2 to 5, then download this demo again and this demo can't work.

    Does anybody know why? Thank you !!

  • I use LPC2378 in MCB2300 and I test usbmem demo and it works well. But when I change the bulk endpoint from EP2 to EP5, this demo works failed. In LPC2378, EP2 and EP5 are for bulk data transfer.

    Does anybody know why. Thank you

  • There are three parts I modify for bulk EP5:
    (1) In usbdesc.c :
    /* Endpoint, EP5 Bulk Out */ USB_ENDPOINT_DESC_SIZE, /* bLength */ USB_ENDPOINT_DESCRIPTOR_TYPE, /* bDescriptorType */ USB_ENDPOINT_OUT(5), /* bEndpointAddress */ USB_ENDPOINT_TYPE_BULK, /* bmAttributes */ WBVAL(USB_CDC_BUFSIZE), /* wMaxPacketSize */ 0x00, /* bInterval: ignore for Bulk transfer */
    /* Endpoint, EP5 Bulk In */ USB_ENDPOINT_DESC_SIZE, /* bLength */ USB_ENDPOINT_DESCRIPTOR_TYPE, /* bDescriptorType */ USB_ENDPOINT_IN(5), /* bEndpointAddress */ USB_ENDPOINT_TYPE_BULK, /* bmAttributes */ WBVAL(USB_CDC_BUFSIZE), /* wMaxPacketSize */ 0x00, /* bInterval: ignore for Bulk transfer */

    (2) In cdcuser.h :
    #define CDC_DEP_IN 0x85
    #define CDC_DEP_OUT 0x05

    (3) In cdcuser.c :
    void USB_EndPoint5 (DWORD event) { switch (event) { case USB_EVT_OUT: CDC_BulkOut (); /* data received from Host */ break; case USB_EVT_IN: CDC_BulkIn (); /* data expected from Host */ break; }
    }

    Does anybody know why. Thank you