HELP! Omap L-137 used as a USB-device does not enumerate!

Hi,

I got the same exact problem on a C6745, i'm using interrupt, and I received always two subsequent status stage!

Does anybody can help about that?

Luigi

In fact, I have found that the second Status stage after the GetDeviceDescriptor is normal, since one is to advice the end of transmition, and the second one is to advice the end of status stage.

But the problem is still after the adress stage, when the second GetDeviceDescriptor is received, the Host doesn't seem to acknoledge the data, and then restart with a Reset.

I was wondering, should it be because the device descriptor is 18 bytes, and since the FIFO0 accepts 4 bytes at a time, we can send 16 or 20 bytes, but how can we send 18 bytes with that FIFO?

Any one have any idea about that?

Hi Luigi (and anybody else interested),

TI had replied to my request of help the following which might be usefull (I still hadn't the time to verify):

 We do not provide direct driver development support. You will find that the USB driver is already supported not only on the DSP side with DSP/BIOS but also on the ARM side through Linux:

http://wiki.omap.com/index.php?title=Category:OMAPL1

If you need support on driver development outside of the TI supported ones, you can either consult with our Third Parties or through the Linux community on the web.

For this, you may want to try the following resources:

http://focus.ti.com/general/docs/gencontent.tsp?contentId=49963

You should also find the USB compliant test an interesting srouce of information:

http://focus.ti.com/lit/an/sprab17/sprab17.pdf

The Linux source code might help to solve the problem, evenso its written for the OMAP-ARM and not for the DSP. But that shouldn't be a big item, since the problem resides obvisiously in setting up the USB registers correctly.

Please let me know what you have found out!

Hi Michael,

Actually, like you said, i'm pretty sure the problem is within the registers or the sequence of acceding register.  I have done many USB devices in the past, and I don't think my driver should be different this time, there is surely something wrong about the controller wich is not indicaded in the datasheet.

i have verify that all of my setup sequences are exactly how it is indicated in the datasheet, and it does this same problem still, i'm trying to contact TI about that, i'll tell you if I find anything about that!

hi Luigi

I have problems the same as you had about USB enumeration on OMAPL137 or C6747.

I tried to solve that but i can't find the answer. 

if you found why it is occured,  please let me know that.

Hi Luigi,

you remeber the problem with setting up the USB-registers on the c67xx DSPs?

Do you have found a solution?

Best regards,

Michael

hi Ho Guen,

you remeber the problem with setting up the USB-registers on the c67xx DSPs?

Do you have found a solution?

Best regards,

Michael

Hi Michael,

did u figure it out?

THX

Hi Bernhard,

no, still i hadn't the time solve this problem.

Do you have the same trouble?

Or a solution?

Have a nice day,

Michael

Hi Michael,

sorry, no. Furthermore i have the problem, that i recieve the initial RESET interrupt from the host, but after that i didn't get anything. So no EP0 interrupt, for the enumeration process.

KR Bernhard

Michel, Bernhard

Any reason the packaged BIOSUSB stack would not be a good fit for your need?  It has all the sequence verified and you just have to fit your app on top of it to get the functionality you want.  Any reason why you would not want to take this path?

regards

swami

hi swami,

unfortunately BIOS (DSP, USB, PSP,..) is no choice for me, because we have to built the system from scratch.

KR

Hi Swami, Hi Bernhard,

I do have the same problem as Bernhard, I have to build the driver up from scratch to fit it to my needs.

Actually I'm a bit upset about the fact that TI does not bother to provide comprehensive documentation about their USB hardware.

Dear Swami, as an TI employee, isn't there anything you could do for 2 stressed developers?

Hopefully,

Michael

Michael,

Let me start my response by expressing a deep sense of regret in hearing that you are not able to make progress with the published documentation.  We typically provide inputs based on the spru documentation to our customers and 3rd parties and so far it has been helpful to getting them past their blocking issues.

Having said that could you refer to the Linux driver under "drivers/usb/musb" directory.  This would exactly translate the spru documentation into a verified flow and probably serve as a reference to understand the flow better.  Pl. refer to

• da830.c for OMAPL13x/C674x related platform specific init/handling information
• musb_core.c generic USB driver init and common code location.  MUSB driver Init starts from musb_probe() function.
• musb_gadget.c handles all the device specific functioinality
• musb_gadget_ep0.c handles all the ep0 related generic protocol handling.

Our licensing model w.r.t BIOSUSB does not permit TI from exposing the source code for the USB stack.  This is the model that we believe delivers better value to our customers for the following reasons

• Customers can focus on their (custom) application while leaving the nittygritty details of the underlying USB IP and platform to be handled by the USB stack. 
• Faster time to market and also customers would get to choose pre-verified, certified USB applications from Jungo (USB stack provider) or customer could choose to develop custom applications on top of the BIOSUSB stack.
• Capabality to re-use existing USB applications if already running on top of existing Jungo USB stack solution on to C674x platform BIOSUSB solution.

regards

swami

Dear Swami,

thank you very much for immediate and very informative response. I hope it will help to get the USB-hardware setup and running. My only problem seems to reside in the correct setup sequence of the USB hardware registers. The stack itself is none of a problem.

I understand TI's policy of providing a readymade solution, but in my case (like I suppose in Bernhards case) this solution is not applicable.

Thanks and best regards

Michael

Hi,sorry to cut into the disscusion.

I'd like to say have you tried to see what is on the bus with a usb bus analyzer.

I have the same problem with you .Have you solved the problem?

I'm prepared to buy a usb bus analyzer to help.

I don't know whether it is of great use to solve the problem.

Thank you .

Hi!

I also have the same problem!

But I use 6745 so there is no BIOUSB stack for that DSP.

What do I have to do?