Upgrading Starterware USB to operate under the USB 2.0 spec

Walter Snafu

Other Parts Discussed in Thread: OMAP-L138

I'm going to answer the first of my two questions: What is required to upgrade Starterware to the USB 2.0 specification?

Answer: The following simple change to usbdbulk.c

unsigned char g_pBulkDeviceDescriptor[] =
{

18, // Size of this structure.
USB_DTYPE_DEVICE,
USBShort(0x200), // was USBShort(0x110) This change will report the USB version as 2.0
....

That change is sufficient to get MS Windows to treat the device as meeting the USB 2.0 specification. This is sufficient for all practical purposes, with two caveats:

With that simple change alone, the device will only operate at "full-speed", which is not the fastest speed. (Many additional Starterware changes will be needed to operate at high-speed.)
The Starterware software might not (???) implement the four "test-modes" needed for full-implementation of the USB 2.0 spec. I believe these physical requirements are built into the OMAP-L138 hardware, but the Starterware software (and the usb_dev_bulk example) does not implement those test-modes, so far as I am aware. (And they're scarcely needed.)

_____________________

Footnote: A comment in Starterware usbdbulk.c says "(if we say [USB] 2.0, hosts assume high-speed - see USB 2.0 spec 9.2.6.6)" But I say that is a needless worry:

The USB 2.0 spec, section 9.6.2 says: "If a full-speed only device (with a device descriptor version number equal to 0200H) receives a GetDescriptor() request for a device_qualifier, it must respond with a request error." -- in other words, a stall. And that is precisely how the Starterware software already behaves. It goes like this: The device start at "full-speed", and reports that it is using USB 2.0. The Host then requests a device_qualifier, to determine whether a speed-increase is in order. Then the Starterware (correctly) stalls that request. So the device remains operating at "full-speed" (not high-speed). There is no problem here.
I tried the above described change, and it works. The device functions well, and MS Windows treats it exactly like a USB 2.0 device.

-- Walter

over 10 years ago

0 Walter Snafu over 10 years ago

Genius 3450 points

My opening post got deleted somehow. (I thought I was "editing" my "reply", but apparently I was "editing" my opening post! I don't know how that happened.... Arrrgh.)

Anyway, I answered part 1 of my question. I explained how to upgrade Starterware to the USB 2.0 specification. It is easy to do.

Part 2 of my question is harder, and my concern now: How do we get Starterware USB in peripheral mode to operate at high-speed (rather than the slower "full-speed")?

My study suggests several things:

"If the HSENA bit in the POWER register (bit 5) was set, the controller also tries to negotiate for
high-speed operation." (OMAP-L138 DSP+ARM Technical Reference Manual, section 35.2.7.1)

That would be done in the file, usb.c, in the function, USBDevConnect().

/* Enable connection to the USB bus. */
#define USB_POWER_HSENA 0x00000020
HWREGB(ulBase + USB_O_POWER) |= (USB_POWER_SOFTCONN | USB_POWER_HSENA);

Also, in usb_dev_bulk mode, see OMAP-L138 DSP+ARM Technical Reference Manual, section 35.2.7.1.2.2, and especially Table 35-5. For high-speed operation, you want normal Ping flow control, which means the DISNYET bit must be cleared in the PERI_RXCSR Register.

Also, the control endpoint (i.e., endpoint 0) should still be set to have a maximum packet size of 64 bytes. But the other endpoints (the bulk-in and bulk-out endpoints) should be set to have a maximum packet size of 512 bytes. This will make a huge difference in the USB bulk throughput.

In configuring an Rx endpoint for Bulk OUT transactions, the RXMAXP and TXMAXP registers must be written with the maximum packet size (in bytes) for the endpoint. This value should be the same as the wMaxPacketSize field of the Standard Endpoint Descriptor for the endpoint. (Sections 35.2.7.1.2.1.1, and 35.2.7.1.2.2.1)

Lastly, it appears Starterware must be upgraded to handle the "device_qualifier" descriptor, and the "other_speed_configuration" descriptor. (See the USB 2.0 specification, sections 9.2.6.6, 9.6.2, and 9.6.4) (Though it isn't yet clear to me, from the USB 2.0 spec, whether a high-speed device must ALWAYS support those two descriptors. Or whether it need only support those two descriptors if it intends to changes speeds.

Any thoughts or clarifications on this?

-- Walter

0 Walter Snafu over 10 years ago in reply to Walter Snafu

Genius 3450 points

I spent time reading manuals. The upgrade to USB 2.0 high-speed is looking easier than I thought.

Make the following simple change to usbdbulk.c

unsigned char g_pBulkDeviceDescriptor[] =
{

18, // Size of this structure.
USB_DTYPE_DEVICE,
USBShort(0x200), // was USBShort(0x110) This change will report the USB version as 2.0
....

In the file, usb.c, in the function, USBDevConnect():

/* Enable connection to the USB bus. */

#define USB_POWER_HSENA 0x00000020

HWREGB(ulBase + USB_O_POWER) |= (USB_POWER_SOFTCONN | USB_POWER_HSENA);

That increase to high-speed occurs nearly immediately, before the enumeration process even begins.

If you intend to operate only at high-speed, then the "device qualifier descriptor" and "other speed configuration descriptor" are not needed. (Yeah!)

The control endpoint (i.e., endpoint 0) must still be set to have a maximum packet size of 64 bytes. But the other endpoints (e.g., the bulk-in and bulk-out endpoints) can be set to have a maximum packet size of 512 bytes. This will make a huge difference in the USB throughput.

Double-buffering the FIFO can further increase the throughput. See my accompanying post on a bug I discovered in the Starterware USB double-buffering routines.

DMA can further increase the data throughput. I'll tackle that in a separate post.

-- Walter Snafu

Processors

Processors forum

Upgrading Starterware USB to operate under the USB 2.0 spec