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?

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

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

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.

"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

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.