OMAPL138: missing standard request during USB 2.0 enumeration

I have fixed the problem with Ellisys hardware analyzer after working with their support.

Normal 0 false false false EN-US ZH-CN X-NONE MicrosoftInternetExplorer4

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)

From the capture of Ellisys hardware analyzer, it is in line with the software analyzer (USBTrace), we see host sending out request to get the string descriptor (iSerialNumber, iProduct), but never got it.

Device firmware does not receive interrupt for these requests, it seems to me that L138 USB 2.0 controller is selectively reject/ignore the request. These requests are appeared on the USB bus (as captured by the Ellisys HW analyzer), but device firmware never receive.

What could possibly go wrong here ???

Wong,

What do you see on the tracer when host sends the GET_STRING_DESC command? Does the device NAKs ir STALLs? If you are using ellisys then make sure that there are to different host one for connectng ellisys to it and another for connected OMAPL138.

Regards,

ajay

Hi Ajay,

Thanks for reply.

From the capture, the device neither NAK nor STALL. There is nothing coming back from device.

I am not sure how NAK work in this case. But for STALL, I think software needs to receive interrupt first, and read the SETUP data and only STALL if there is request error.

From my investigation, the software does not even receive interrupt for those missing requests.

rgds,

kc Wong

Hi Ajay,

I would like to ask the same question again. 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.

 In SPRS586B-JUNE 2009-REVISED AUGUST 2010, there is an Important Notice (does not appear on REVISED AUGUST 2009).

Important Notice: The USB0 controller module clock (PLL0_SYSCLK2) must be greater than 30 MHz for proper operation of the USB controller. A clock rate of 60 MHz or greater is recommended to avoid data throughput reduction.

I am a bit confused here, are they refering to the same clock ? If yes, then 24MHz is not fast enough for the PHY to have proper operation ?

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

This clock would not be related to the issue of "not getting string descriptor" command from PC. This has to do something with software settings. Are you sending DEVICE_QUALIFIER descriptor also ?

Regards,
Ajay

Yes, I am sending DEVICE_QUALIFIER descriptor also.

But, so far, I never see the host asks for it from the traffic capture.

So, what software settings that you think that could cause this issue ?

rgds,

kc Wong

You need to review the descriptor data being sent to host in high speed mode. You can also capture the enumeration data from any standard pen drive to PC and compare the requests and data and see if anything being sent incorrectly.

Ajay

We are building USBTMC device. And I have compared the descriptors with the existing shipped product which is in high speed mode also, but using Cypress USB chip. And I don't see any anything incorrect.

Furthermore, the same set descriptors are used in full speed mode, and does not exhibit this problem.

Actually, the device has enumerated succesfully and is listed under Device Manager (see attached). But somehow, the string descriptors are missing and these are optional descriptors.

rgds,

kc Wong

4527.Differences in Full-Speed and High-Speed.docx

I noticed that the message GetDescriptor(String lang IDs) sometimes succeeds and sometimes fails. I would guess you are on the threshold of being too slow to respond. Is there any time consuming processing involved with the response to GetDescriptor(String)? Some OS'es allow printing from ISRs. Try to avoid that.

Yes, that's true that GetDescriptor(String lang IDs) sometimes succeeds and sometimes fails. I am still not able to figure it out why.

Initially, I have also been thinking that the device is on the threshold of being too slow to respond. But, with the below 2 points, I don't think it is the case.

1. My understanding on USB standrard that the timing requirement for both full-speed and high-speed are the same. If it fails at high-speed, then the same thing should happen on full-speed. But, this is not the case.

2. I have done an experiment by deliberately adding an empty while loop just after reading the SETUP packet and before the start of processing. I remember it is about tens of thoushand of loop before the enumeration start to fail. So, it is pretty much prove that the device's response is fast enough. Furthermore, what I see from the analyzer capture is a lot of NAKs which indicate a slow respond device. But, this is not the case for GetDescriptor(String), the device just doesn't respond at all, there is no NAK nor ACK.

One question about this USB controller for SETUP transaction. The ACK packet is automatically generated by hardware, OR it has to be after the device driver has read the SETUP packet from the FIFO, then only hardware will generate it ???

SETUP transaction

-> SETUP packet

-> DATA0 packet

<- ACK packet

Hardware will automatically send the ACK as soon as the SETUP packet is received in FIFO successfully without any error .

Regards,

Ajay

KC Wong -

Kiung Chung Wong said:

One question about this USB controller for SETUP transaction. The ACK packet is automatically generated by hardware, OR it has to be after the device driver has read the SETUP packet from the FIFO, then only hardware will generate it ???

From a USB IP point of view, a device will respond with an 'ACK' if the Token Packet is Valid, and the Data Packet is received within the specified timing requirement of USB spec 2.0.

If the device receives a  non-valid Token Packet, or the DATA0 packet is not sent within the specified USB timing, the device will not respond with either an ACK nor a NACK - it will simply ingore the data. You can refer to 8.5.3 in the USB 2.0 Specification for a diagram.

From your Descriptors, you know that the Elysis analyzer is receiving the GET_DESCRIPTOR Token Packet, however we don't know if the OMAP-L138 is receiving it or not.

 Summary

 - GET_DESCRIPTOR (string) is being sent from Host - no issue with host software

 - GET_DESCRIPTOR (string) is being coded by Elysis - no issue with Elysis

-  GET_DESCRIPTOR() is a zero length data packet - There shouldn't be a valid DATA0 packet following the GET_DESCRIPTOR Token Packet.

- OMAP-L1x does not generate an interrupt.

From USB 2.0 Spec, for a control transaction with errors, the device simply ignores the packet. - this would seem to indicate that there the packet is not being sent from the Elysis to the OMAP-L1x device correctly, or that there are some signal integrity issues between the Elysis and the OMAP-L1x that would cause the packet to be ingored (due to error).

Is there a long cable between the Elysis and the OMAP-L1x? Is the Cable USB 2.0 Certified?

Kiung Chung Wong said:

Furthermore, the same set descriptors are used in full speed mode, and does not exhibit this problem

Since it works at full speed (12Mbps) but doesn't work at high speed (480Mbps), this really seems like it's a signal integrity issue.

Also - does the Host, Elysis, and OMAP-L1x device share the same ground return (from a power supply point of view). Are there any ground loops in your system.

Hi Ajax,

Then, the next question would be why the hardware does not send the ACK ???

rgds, kc wong

Hi Drew,

I would like to clarify that the problem is not only happen with Ellysis analyzer connected. As long as it is high-speed, it happens with or without Ellysis analyzer connected. So, i think it is wrong to say that the packet is not being sent from the Ellysis to the OMAP-L1x device.

I have been using a very short cable (< 10cm). And I think it is USB 2.0 Certified, because the cable is actually being used for USB compliance test.

I am not sure how to answer your question about the ground loops ??? Let say, without Ellysis analyzer, the connection between PC and OMAP-L1x device is just a USB cable, does this make them share the same ground return ???

rgds,

kc Wong

Kiung Chung Wong said:

I would like to clarify that the problem is not only happen with Ellysis analyzer connected. As long as it is high-speed, it happens with or without Ellysis analyzer connected. So, i think it is wrong to say that the packet is not being sent from the Ellysis to the OMAP-L1x device.

Agreed - I didn't realize that you still see the same issue without the Elysis attached.

Kiung Chung Wong said:

I am not sure how to answer your question about the ground loops ??? Let say, without Ellysis analyzer, the connection between PC and OMAP-L1x device is just a USB cable, does this make them share the same ground return ???

Are the EVM and the Host PC connected to the same wall recepticle?

No, they are not connected to the same wall recepticle.

rgds,

kc Wong

Actually, I have created  a simple USB COM port application. There are high-speed version and full-speed version. The only difference is whether or not the high-speed is enabled.

 /* Enable high-speed */
 USB_OTG->POWER |= USB_OTG_POWER_HSEN;

First of all, you need to replace the UBL in the SPI flash with arm-spi-ais-debug-usb.bin with SFH (serial flasher host). In this new UBL, I have added in the USB PHY configuration following User Guide for USB controller.

Then, you need to download the application (either hs_virtual_com_port.bin or fs_virtual_com_port.bin) into flash using TFTP in U-boot as shown below. Note that I have modified UBL to be able to choose the image to boot. During power up, you have to keep pressing ‘n’ to jump to the third option to boot U-Boot. You can follow the below for detailed steps.

Once this is done, you can now boot the application. You can compare between HS and FS in Device Manager, they will appear under Ports (COM & LPT). In the package, I also include the INF file for the USB virtual COM port. I believe you system should have the corresponding driver which is usbser.sys.

rgds,

kc Wong

Chip initialization passed!

Creation date: Dec 15 2010 14:06:12

Booting with TI UBL

Device OPP (300MHz, 1.2V)

Booting Catalog Boot Loader

BootMode = SPI 1 Flash

Boot from 0x00300000 (vxWorks application)? y/n

Boot from 0x00600000 (vxWorks bootrom)? y/n

Boot from 0x00010000 (U-Boot)? y/n   ß boot U-Boot

Starting SPI Copy...

UBOOT header : (magicnumber, entry, appsize , ldAddress) - (0xA1ACED00 ,0xC1080000 ,0x000264DC ,0xC1080000 )   DONE

Jumping to entry point at 0xC1080000.

U-Boot 2009.11 (May 03 2010 - 15:38:40)

I2C:   ready

DRAM:  64 MB

In:    serial

Out:   serial

Err:   serial

ARM Clock : 300000000 Hz

DDR Clock : 132000000 Hz

Net:   Ethernet PHY: GENERIC @ 0x00

Hit any key to stop autoboot:  0

U-Boot >

U-Boot > tftp c3e00000 hs_virtual_com_port.bin

Using  device

TFTP from server 141.183.191.67; our IP address is 141.183.191.70

Filename 'hs_virtual_com_port.bin'.

Load address: 0xc3e00000

Loading: #################################################################

         ##########################

done

Bytes transferred = 1321792 (142b40 hex)

U-Boot > sf probe 0

8192 KiB M25P64 at 0:0 is now current device

U-Boot > sf erase 0x300000 0x300000

U-Boot > sf write c3e00000 0x300000 0x300000

U-Boot >

4135.USB virtual COM port.zip

Just comparing my Ellisys output with yours. Mine has a "High Speed Detection Handshake" when starting up. Is that just off the screen on your screen captures?

Ya, the "High Speed Detection Handshake" is not there. I think it is because there is a high-speed hub in between the device and the analyzer.

I have tried with our existing shipped product which is a high-speed USBTMC device. With the high-speed hub in between that device and the analyzer, the "High Speed Detection Handshake" will not be there. Without the hub, there is "High Speed Detection Handshake".

By the way, are you trying the virtual COM port application I posted early on ?

Hi,

Not sure if TI can provide help to root cause this issue. Any suggestion for me how to continue ? Or is there any kind of paid service that TI is offering to help in this case ?

The USBTMC device is fully functional in full-speed mode. We want it to work in high-speed mode as well.

Appreciate any help or any suggestion.

rgds,

kc Wong

KC -

   Does the device pass the USB 2.0 Eye test? It's a difficult test to pass, but required for USB 2.0 certification in a product.

Also you may the OMAP-L1x USB checklist helpful for additional ideas.

Hi Drew,

From TI document "TMS320C6748/46/42 and OMAP-L1x8 Universal Serial Bus Upstream Device Compliance Testing (SPRAB51–August 2009)", it should have passed at least at the chip level.

But, I am not sure if LogicPd do the same test at the board level or not for the eXperimenter Kit.

rgds,

kc Wong

KC -

   Valid Concern. You might want to dig through the LogicPD documentation to see if they did USB 2.0 Compliance testing on the board or not. This should be included in the download documentation if they did pass 2.0 certification.

Hi Drew,

Attached is the document I got it from LogicPD. I don't know how to interpret the result, but as I look at the high-speed eye diagram, I think it is not that clean and the signal is distorted. I am not sure does it meet the spec but the document says PASS.

3173.OMAP_L138_EVM_DVT.pdf

 By the way, as I go through T1 Application Report SPRAB50 - August 2009 (TMS320C6748/46/42 and OMAP-L1x8 Universal Serial Bus Downstream Host Compliance Testing), I actually don't see eye diagram for high-speed. I only see Full-Speed Eye Diagram (Figure 23) and Low-Speed Eye Diagram (Figure 26).

Thus, I can't be sure if the controller has passed the High-Speed Eye Diagram Test at the chip level.

Any comment ???

rgds,

kc Wong

KC,

   Thanks for the feedback and document from Logic.

Refer to section 4.2 of SPRAB50 for High Speed compliance testing. Figure 3 is the downstream Eye Diagram for USB High Speed. and Table 6 are the associated High Speed Measurements. Note that this testing was done an an internal silicon validation / debug board during device bring up and not the LogicPD SOM / Baseboard

Drew,

Thanks for pointing that out. I overlooked that because it only says "Downstream Eye Diagram" for Figure 3. Yes, I understand that it is at the silicon level validation.

By the way, do you think the high-speed eye diagram in LogicPD is good enough to pass the spec at the board level ???

rgds,

kc Wong

Just wondering. Did the high speed USB work using the Linux kernel that came with the EVM?

KC,

Kiung Chung Wong said:

I overlooked that because it only says "Downstream Eye Diagram" for Figure 3.

Kiung Chung Wong said:

By the way, do you think the high-speed eye diagram in LogicPD is good enough to pass the spec at the board level ???

I don't think I can make a conclusive argument either way based upon the single capture from the document. At some points it looks like it could work, but at others, it looks like it might be approaching the threshold - but again, difficult to say.

By the way - can you upload your Elysis (.ufo) file to the forum that shows the transactions. I couldn't always determine the data in the screen captures you supplied? I'm not sure it it will help solve the problem, but it would be good to see what the Elysis is reporting.

That's something I am wondering also. We never try the USB driver on Linux before we convert everything to VxWorks.

Actually, that's what I plan to do, but I have no time to do it now.

8053.pass_enumeration (missing string descriptor).txt

Thanks, Drew.

By the way, you may change the file extension to .ufo after download. I am not able to upload the file with extension .ufo, thus I changed it to .txt.

Note that there are 2 devices in the capture. Device address 1 is actually a hub, and the device address 2 is the device we are concerned about.

The hub is needed here in order for Ellysis to capture the high-speed traffic correctly.

rgds,

kc Wong

Seems odd to me that Ellisys requires a hub. My board was a OMAP-L137 EVM from Spectrum Digital. My setup was:

PC(on MB) <-> analyzer <-> device
PC(on PCI card) <-> analyzer

The PC <-> analyzer USB cables are about 2ft/60cm long. The analyzer <-> device cable USB cable is about 4ft/1.2m long. I had no problems at both full speed and high speed.

I would have thought that the L137 and L138 would be behave the same. I don't think there is lot of differences in the USB HW external to the chip. Quite a puzzle.

Sorry that I accidentally hit the Verify answer button.

This is excatly why I think there is a signal integrity issue. As I pointed out in the early of this post, I had difficulty to capture high-speed traffic with L138 eXperimenter Kit initially(no problem with full-speed).

After working with Ellysis support, below are their suggestions to me:

(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)

Yeah, I saw your setup in your second post. There is certain recurring theme of L138 USB problems on this forum. Too soon to blame the chip yet.

I think you can "unverify" a post. Turn it back to "red" ro draw TI's and the community's attention.

I am not blaming the chip. I am just asking for help ...

By the way, you said you got the L137 EVM from Spectrum Digital, do they sell EVM for L138 ?

Maybe I should get one from Spectrum Digital to try instead of LogicPD.

rgds,

kc Wong

I've checked their website, http://www.spectrumdigital.com and I can't find any mention of a L138 EVM. I only know of LogicPD and Hawkboard EVMs for L138. Hawkboard has got issues right now. There are probably others, I haven't looked very far. My customer's requirements selected the L137 over the L138. I might be in the same position as you if the L138 has been chosen.

Thanks Norman for the effort to check. Appreciate that.

Hi Drew,

Not sure if you see anything peculiar in the capture ?

rgds,

kc Wong

KC,

  I didn't see any thing that was a smoking gun in terms of what the protocol analyzer picked up. I spoke with the internal Linux Driver Guru's and they claim that it works with the release by TI.  Were you able to try this out?

Thanks Drew.

Did they test on L138 eXperimenter Kit from LogicPD or other hardware ?

Without the string descriptor, the enumeration can still work. It just don't get the product name and the serial number correct. Did they verify the string descriptor ?

Sorry for asking the details. I just want to find out the reason for this issue.

It actually is our plan to convert it back to Linux, and try. But, because we have development going on VxWorks, we don't have time to do this at the moment.

Anyway, thanks for taking the effort to look at the capture.

rgds,

kc Wong

Hi Drew,

With Ravi's help, I have managed to bring up the USB Ethernet/RNDIS Gadiget in Linux.

http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/122854/438931.aspx

It exhibits the same problem for GetDescriptor(string iProduct) requests during the enumeration, there is no ACK packet. So, what should I do next ?

?

rgds,

kc Wong

Same issue is seen during enumeration for Linux-USB Serial Gadget. I have modified drivers/usb/gadget/serial.c to provide iSerialNumber.

Hi Drew,

I have modified drivers/usb/gadget/ether.c to provide iSerialNumber and capture again the USB bus traffic during enumeration.

As you can see both GetDescriptor(String iProduct) and GetDescriptor(String iSerialNumber) are failed.

rgds,

kc Wong

I don't suppose you have tried swapping out one bit of HW at a time. Maybe try a different cable. I seen one case on this forum where the cable mattered to this particular board. Maybe try a different PC or another board if you've got one. Yeah, it's a desperation move.

Thanks, Norman. I have tried them before. But, not with these Linux gadget, but my own driver.

The device just seems to always ignore the GetDescriptor(String iProduct) and GetDescriptor(String iSerialNumber) requests.

I doubt my own driver initially, but now it proofs that same thing happens in these Linux gadget as well.

Make me more confirmed that something is not right at the board level.

rgds,

kc Wong

It doesn't look like you are getting much traction with TI in your other thread. Maybe try the LogicPD forum. Can't tell if it has anything useful. Need to register to view.

Perhaps compare your USB schematic against the Spectrum Digital OMAP-L137 EVM. I know that one does high speed.

Really frustrated for not getting any response in the other thread.

Right now, we only hope that this is caused by the long trace length (> 10cm) between the USB connector and USB controller (OMAP L138) on the eXperimenter Kit.

By the way, do you know this length for Spectrum Digital OMAP-L137 EVM ?

Or do you know what is the next level of support that I can get from TI ? Or the channel to escalate the issue ?

rgds,

kc Wong

I don't know any procedure for escalating an error. I'd probably contact my FAE. Although my FAE usally sends me here.

When I get into work tomorrow, I can try to visually estimate the distance from the connector to the OMAP. My memory says it's about 6 cm. Maybe your trace is routed nearby to something noisy. Unlike LogicPD, Spectrum Digital support file are publically available here:

http://support.spectrumdigital.com/boards/evmomapl137/revg/

To bad that I don't even have FAE to contact to. TI E2E Community is my only channel.

On eXperimenter Kit, the trace eventually will reach a connector, which will be connected to SOM board. The OMAP L138 is on SOM board.

Thanks for reply.

Hi Kiung,

Would like to appologize for not responding on time. Somehow your post fell in the cracks and happen not to see it.

I would like to start by saying that we have not seen any problem of your kind. This device has been used by many customers and the peripheral you are using is a proven peripheral and I think the problem most likely lies with the setup other than the device.

What you are saying is that the device is unable to respond to GET_DESCRIPTOR request. This is not possible and the reason for this is that the device does not know any specific commands. The S/W is the one that is going to decipher the recieved request. The device is aware of a SETUP packet and ensures that it receives 8 bytes of data. That is pretty much it. The H/W would then send an ACK to the Host and at the same time generates an interrupt to the User. The User App S/W should then read the 8-byte request and decipher what the request is.

In other words, the problem you are seeing has to do with the content of the 8-bytes. If the device receives other request, I think somehow the request is not being parsed properly.

If the hardware is not responding with a reply (ACK, NAK, or STALL) then that means that there is a problem with the SETUP Packet. The Packet is either damaged or is not confirming with the standard.

Not sure as to how FS works and why HS is not working. This is a very conflicting info.

One thing I may suggest is that for you to use a LINUX image to prove that the device is working. Please let us know if this satifies your need. Not sure about the distributing policy but if there is not restriction, I can arrange to ship or email one to you. If you are able to get another EVM, that is a good thing to try too.

Thanks and best regards, Zegeye