USB controller - LPC2364

 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?

 RE: USB controller - LPC2364

Paul;
I'm sure not qualified to give you any advice on the direction of your project. But, I can suggest that you search this forum for USB info. In thread 11137, Tsuneo gives a virtual USB implementation tutorial with many links to debugging aids and specifications.
There are several other threads that have very useful information.
Bradford

 RE: USB controller - LPC2364

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: http://www.voti.nl/shop/catalog.html?USB-PID-10

- 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

http://www.usb.org/developers/vendor/

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 */
...

 RE: USB controller - LPC2364

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

 RE: USB controller - LPC2364

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

 RE: USB controller - LPC2364

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.

 RE: USB controller - LPC2364

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?

 RE: USB controller - LPC2364

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.

 RE: USB controller - LPC2364

"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
http://www.microsoft.com/whdc/connect/usb/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"
http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/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

 RE: USB controller - LPC2364

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?

 RE: USB controller - LPC2364

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

 RE: USB controller - LPC2364

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.

 RE: USB controller - LPC2364

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

 RE: USB controller - LPC2364

"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

 RE: USB controller - LPC2364

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!

 RE: USB controller - LPC2364

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 !!

 RE: USB controller - LPC2364

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

 RE: USB controller - LPC2364

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

 RE: USB controller - LPC2364

Stay in your own thread, and don't attack every thread you can find that has with USB to do...
http://www.keil.com/forum/docs/thread13496.asp

 RE: USB controller - LPC2364

Tsuneo,

I did get this all working, I am trying to now port this to a 2468 processor. I started with a similiar Keil mass storgae device example for 24xx, comparing all the files there were minimal differences, mostly the USB_Init and ISR routines. After making the changes and carefully double checking I can not get the host to recognize the device.

I'm running out of debugging ideas, is there anything you can suggest? I do see the IUSB_SR firing on reset, it executes a USB_Suspend () and USB_Reset(), then the ISR never seems to execute again.

 RE: USB controller - LPC2364

"I do see the IUSB_SR firing on reset, it executes a USB_Suspend () and USB_Reset(), then the ISR never seems to execute again.

Your description is interpreted that no signaling comes from the host side, except for the very early one of the device connection.

Sound like the problem of D+ pull-up resistor (1.5k).
Host side (PC root hub or external hub) detects the connection of the device seeing the voltage change of D+ line, caused by this resistor. As the host side doesn't detect the device connection, no signaling comes from the host.

Depending on your board, this resistor is,
a) fixed one
b) controlled by a port of the chip using a transistor (PNP or Pch FET)

a) fixed one
Check the soldering of D+ pull-up resistor.
Or check the voltage supply to this resistor.

b) controlled by a port
Enable D+ pull-up resistor after finishing initialization of the USB SIE.

Tsuneo

 RE: USB controller - LPC2364

Thanks, that was the first thing I suspected as well. Turns out the new board I was porting to has a different clock speed, once I adjust the clock registers all was well.

Thanks again.

 RE: USB controller - LPC2364

Tsuneo,

If I may impose again, I just started seeing a problem when I happen to send USB packets of exactly 64 bytes. I am actually sending 4 separate packets of 64 bytes each from the device up to the host. (In between sends I wait for the USB ISR to set a flag that tells me the buffer has been read). The host seems to get this as 1 big packet of 256 bytes. I am looking at a USB packet sniffer (SourceUSB) and I see this 1 big packet sent over. As an experiment if I set the packet size to 63 or 65, I see 4 distinct packets being sent.

 RE: USB controller - LPC2364

Do you send a zero-byte packet after the 64-byte packet, to tell the receiving side that 64 bytes really is the full amount of data?

 RE: USB controller - LPC2364

I do not. Yes, this must be the problem, how else would the host know the entire response has been received. Thanks!

 RE: USB controller - LPC2364

"As an experiment if I set the packet size to 63 or 65, I see 4 distinct packets being sent."

65 bytes packet is not fine, because its size exceeds wMaxPacketSize (= 64 bytes).



"how else would the host know the entire response has been received."

As Per said, you have to send ZLP (Zero-Length Packet) to finish the transfer, when the last transaction (packet) is just 64 bytes. No other way.

Windows usbser.sys (CDC device driver) assigns 4K bytes of real memory for DMA to the host controller, to receive each bulk IN transfer. ie. 4K bytes is the expected transfer size.
While the device sends full (64 bytes) packets, the host controller regards that the transfer continues, and hold the data on this 4K bytes buffer. When the device sends a short packet (less than 64 bytes, including ZLP), the host controller takes it the end of transfer, and it passes the entire transfer on the buffer to the device driver.

Short packet (including ZLP) cuts off the expected size of transfer.
4K bytes is the page memory size of PCI bus, max real memory size for single DMA session.

Tsuneo

 RE: USB controller - LPC2364

Not sending the 0 length packet was indeed the problem. By the way my last post was misleading, I never attempt to send more than 64 bytes, larger packets are first broken up to smaller (max 64 bytes) packets and sent individually.

Thanks again for your repsonse.

 RE: USB controller - LPC2364

Tsuneo,

If I may I have another question. I would like my device to detect when the host connected and disconneted. Probably not just physically connected but rather when the commuication pipe has been establised or broken. If you recall I am using a modified verstion of the Keil mass storage driver, all our communication is done over BULK endpoints. I did experiment with this a bit by setting breakpoints in the USB ISR but I either could not find what I wanted or did not hita breakpoint when I thought I should. I do sometimes have trouble with breakponts being recognized when debugging some of the USB code, code I know that is executing. Any suggestions where how to detect pipe connection events?

 RE: USB controller - LPC2364

"Any suggestions where how to detect pipe connection events?"

You have to send the notification actively from your host app to the device.
- Send a command (notification) over the bulk pipe
OR
- Send a vendor request over the default EP
OR
- Add new bulk or interrupt OUT endpoint and use it for the notification.

Nothing is sent to device when the host app opens / closes the device.
If you watch the USB traffic over a sniffer, you'll be aware that no traffic occurs when you are stepping through CreateFile / CloseHandle or WinUsb_Initialize / WinUsb_Free on the host app.

The connection of device and the PC device driver is established when the device is plugged into the USB port, over enumeration. Open on the host app establishes connection between the host app and the device driver. Then, Open/Close on the host app doesn't affect to the connection between the device and the device driver.

Tsuneo

 RE: USB controller - LPC2364

Thanks. Perhaps physical detection on connect/disonnect will suffice. These should be detectable events correct? I experimented with this in the past, setting breakpoints at the ISR and seeing what get executed when I physically connect and disconnect USB. This was sometimes problematic as it seems that Keil debugger has problems hitting breakpoinrs in ISR.

 RE: USB controller - LPC2364

So this was the problem on the device side. The host side (being devleoped by a third party and using WinUSB) is having some problems with the 0 length packet. The device appropriately sends this 0 length packet after the 64 byte packet, but the host thinks it got some data associated with the 0 length packet. No data sent is confirmed by a USB sniffer. I beleive the host is just attempting to read whatever next information might aynchronously be sent by the device, and somehow it is interpretting this 0 packet as having data.

 RE: USB controller - LPC2364

"The host side (being devleoped by a third party and using WinUSB) is having some problems with the 0 length packet. The device appropriately sends this 0 length packet after the 64 byte packet, but the host thinks it got some data associated with the 0 length packet."

When the device sends just the size host requested, device doesn't attach zero-length packet (ZLP), even when the size is just the multiple of 64 bytes.

ZLP is attached when,
- the host requests more than the size device to send
- the device sends just the multiple of 64 bytes.

For WinUsb_ReadPipe, its BufferLength parameter is the size host requests.

I explained it more in details in this post.
Termination of transfer
http://www.cygnal.org/ubb/Forum9/HTML/001627.html

Tsuneo

 RE: USB controller - LPC2364

I have been trying to find a place to download the WdfCoInstaller01005.dll. Where did you find it? I couldn't find it rummaging through the MS site (and we even have the subscription). Thanks.

 RE: USB controller - LPC2364

"I have been trying to find a place to download the WdfCoInstaller01005.dll."

WdfCoInstaller01005.dll is included in the old release of WDK.
But for new design, use the latest version.
The number after "WdfCoInstaller" shows the version.

Tsuneo