OMAP L138: when to enable high-speed for USB 2.0

Which host are you connecting the device to? If you set D5 bit then device will try to get enumerated at high speed but if host supports only Full speed then device should work in full speed mode even with D5 bit set.

Ajay

I am connecting the device to my laptop.

I tried all the USB port on my laptop, the device will not enumerate if I set D5 bit according to the user's guide.

By right, if the port only supports full-speed, the device should enumerate in full-speed mode like what you said. But, it does not enumerate.

Without setting D5 bit, the device is able to enumerate in full-speed mode.

rgds,

kc Wong

Hi,

I am developing USB driver on eXperimenter Kit from Logic PD. I think I know the reason why the device does not enumerate in high-speed mode.

I have a lot of debug printf inside the driver code, I think they slow down enumeration in high-speed mode.

As I remove them, the device is now able to enumerate in high-speed.

rgds,

kc Wong

Hi Ajay,

 My driver can always enumerate in full-speed mode. But it will fail to enumerate in high-speed mode from time to time, and Windows (PC host) will report "USB Device Not Recognized".

I guess in order to work in high-speed mode, the driver code must be very efficient, am I right ? What are the thing that I need to pay special attention.

I still can't figure out why because my driver code is almost identical with the implementation in Linux.

And I handle the whole enumeration process in the ISR context.

rgds,

kc Wong

Wong,

Do you have USB traffic analyzer to see what happens on the bus when you see the failure ?

Regards,

ajay

Ya, i am using Ellisys USB Analyzer.

Attached is the data during the eunmeration in high-speed mode.

There are lots of  "Invalid packet" and "Invalid transaction" which I don't see if it is enumerating in full-speed mode.

The first transfer shows "Get descriptor" and data section says "No DATA" . Do you see any valid data inside this transfer (you can open '+') ? I am wondering how SET address and other commands can proceed when there is no valid data in first transfer itself.

Ajay

 As I expand the "GetDescriptor" and "SetAddress", I can see "Incomplete SETUP transaction".

What is missing is there is no Handshake Packet after SETUP packet and DATA0 packet.

I am not sure will this be related to PHY PLL clock frequency.

I set it to 24MHz as follow to the example in the user guide.

 /* Configure PHY with the Desired Operation */
 // OTGMODE
 SYSTEM->CFGCHIP[2] &= 0xFFFF9FFF; // 00= > Do Not Override PHY Values
 //SYSTEM->CFGCHIP[2] |= 0x00003000; // 11= > Override PHY Values, force host, VBUS low
 //SYSTEM->CFGCHIP[2] |= 0x00002000; // 10= > Override PHY Values, force device

 // PHYPWDN
 SYSTEM->CFGCHIP[2] &= 0xFFFFFBFF; // 1/0 = > PowerdDown/ NormalOperation

 // OTGPWRDN
 SYSTEM->CFGCHIP[2] &= 0xFFFFFDFF; // 1/0 = > PowerDown/ NormalOperation

 // DATAPOL
 SYSTEM->CFGCHIP[2] |= 0x00000100; // 1/0 = > Normal/ Reversed

 // SESNDEN
 SYSTEM->CFGCHIP[2] |= 0x00000020; // 1/0 = > NormalOperation/ SessionEnd

 // VBDTCTEN
 SYSTEM->CFGCHIP[2] |= 0x00000010; // 1/0 = > VBUS Comparator Enable/ Disable

 /* Configure PHY PLL use and Select Source */
 // REF_FREQ[3:0]
 SYSTEM->CFGCHIP[2] |= 0x00000002; // 0010b = > 24MHz Input Source
 
 // USB2PHYCLKMUX: Select External Source
 SYSTEM->CFGCHIP[2] &= 0xFFFFF7FF; // 1/0 = > Internal/External(Pin)
 
 // PHY_PLLON: On Simulation PHY PLL is OFF
 SYSTEM->CFGCHIP[2] |= 0x00000040; // 1/0 = > On/ Off

 /* Wait Until PHY Clock is Good */
 while ((SYSTEM->CFGCHIP[2] & 0x00020000) == 0); // Wait Until PHY Clock is Good.

For complete SETUP transaction, i will see the below packet.

-> SETUP packet

-> DATA0 packet

<- ACK packet (this is the Handshake Packet that is missing and cause the "Incomplete SETUP transaction" error)

Question:

Does the hardware send ACK automatically when receive SETUP packet (likewise when receive data in Data stage) ? Or the ACK is only set after SERV_RXPKTRDY bit (bit 6) is set by the software. I believe hardware should send the ACK without involving software, am I right ?

Second thing, I don't think it should be related to the efficiency of the driver code. Because if the device can enumerate in full-speed, it should enumerate in high-speed becasue the time constraint for both speeds are the same.

USB Specification 2.0

For standard device requests that require no Data stage, a device must be able to complete the request and
be able to successfully complete the Status stage of the request within 50 ms of receipt of the request. This
limitation applies to requests to the device, interface, or endpoint.
For standard device requests that require data stage transfer to the host, the device must be able to return the
first data packet to the host within 500 ms of receipt of the request. For subsequent data packets, if any, the
device must be able to return them within 500 ms of successful completion of the transmission of the
previous packet. The device must then be able to successfully complete the status stage within 50 ms after
returning the last data packet.
For standard device requests that require a data stage transfer to the device, the 5-second limit applies. This
means that the device must be capable of accepting all data packets from the host and successfully
completing the Status stage if the host provides the data at the maximum rate at which the device can accept
it. Delays between packets introduced by the host add to the time allowed for the device to complete the
request.

Wong,

[Does the hardware send ACK automatically when receive SETUP packet (likewise when receive data in Data stage) ? Or the ACK is only set after SERV_RXPKTRDY bit (bit 6) is set by the software. I believe hardware should send the ACK without involving software, am I right ?]

Right! Hardware would send it automatically.

[Second thing, I don't think it should be related to the efficiency of the driver code. Because if the device can enumerate in full-speed, it should enumerate in high-speed becasue the time constraint for both speeds are the same.]

Correct. This looks like something improper at usb circuitry level. HAve you done any modification to OMAPL138 EVM ?

-Ajay

This is the eXperimenter Kit from Logic PD. There is no modification on the hardware.

For software side, the USB driver is running on vxWorks instead of Linux.

Could they be any configuration different needed to be done (for example, register setting with different value) when operate in high-speed mode ?

The pull up resistor connected to D+ (identification for full-speed) needed to be removed when operate in high-speed mode (according to the link below), I suppose this is also done automatically by hardware ? Or software needs to explicitly set something to remove this  pull up resistor to switch high-speed mode ?

http://www.beyondlogic.org/usbnutshell/usb2.shtml

Wong,

There is no software settings for D+ pull up removal. All this is done by hardware only. There is one software setting inside POWER register D5 bit which is HSENAB, I hope you have set this bit. Can you provide the value of POWER and DEVCTL register after musb initialization is completed and also at the time when you see this failure.

Regards,
Ajay

There are two cases:

(1) Power up without connect USB cable to host

Before enumeration

POWER 0x61

DEVCTL 0x80

After enumeration

POWER 0x71

DEVCTL 0x99

(2) Power up with USB cable connected to host

Before enumeration

POWER 0x71

DEVCTL 0x98

After enumeration

POWER 0x71

DEVCTL 0x99

Just some note, I have not yet implement handler for other interrupts besides EP0 interrupt. I guess that does not matter because it works in full-speed mode.

I guess that could be compatibility issue with Ellisys USB (hardware-based) Analyzer. The device is able to enumerate successfully in high-speed mode if connecting directly to the PC host without going through the analyzer.

I have verified with software-based USB analyzer, like SourceUSB and USBTrace, the descriptors are correct.

rgds,

kc Wong

Just to update for the community benefit, whoever is using Ellisys Explorer 200 or 260.

I have worked with the Ellisys support, and it is suspect that the signal from the physical layer could be too weak for the analyzer and reach the PC host.

To get this working:

(a) use a very short USB cable (I am using < 10cm USB cable)

(b) let the signal from device goes through hub before entering the analyzer, so the hub will regenerate the electrical signal (PC <-> analyzer <-> hub <-> device)

I am wondering, is there any setting that can affect this in Chip Configuration 2 Register (CFGCHIP2) as it controls USB2.0 OTG PHY ???