View topic - usb detection problem in omap3530( gumstix overo fire)

usb detection problem in omap3530( gumstix overo fire)

anything that doesn't fit to other groups.

usb detection problem in omap3530( gumstix overo fire)

Postby Ericxx » Thu Aug 26, 2010 1:08 pm

Hello all,

I am debugging a usb device on qnx and i have two develop machines. One is native QNX632 installed on a laptop, the
other is the gumstix overo fire with the 6.5.0 image installed. Here is the output of "usb -vvv" on tow platforms:

1. on the laptop where the detection is ok:
USB 0 (UHCI) v1.10, v1.01 DDK, v1.01 HCD
Control, Interrupt, Bulk, Isoch, Low speed, Full speed

USB 1 (UHCI) v1.10, v1.01 DDK, v1.01 HCD
Control, Interrupt, Bulk, Isoch, Low speed, Full speed

Device Address : 1
Upstream Host Controller : 1
Upstream Device Address : 0
Upstream Port : 0
Upstream Port Speed : Full
Vendor : 0x15d1 (Hokuyo Data Flex for USB)
Product : 0x0000 (URG-Series USB Driver)
Device Release : r1.00
USB Spec Release : v2.00
Serial Number : N/A
Class : 0x02 (Communication)
Subclass : 0x00
Protocol : 0x00
Max PacketSize0 : 64
Languages : 0x0409 (English)
Current Frame : 507 (1024 bytes)
Configurations : 1
Configuration : 1
Attributes : 0xc0 (Self-powered)
Max Power : 100 mA
Interfaces : 2
Interface : 0 / 0
Class : 0x02 (Communication)
Subclass : 0x02 (Abstract)
Protocol : 0x01
Endpoints : Control + 1
Endpoint : 0
Attributes : Control
Max Packet Size: 64
Endpoint : 3
Attributes : Interrupt/IN
Max Packet Size: 16
Interval : 16 ms
Interface : 1 / 0
Class : 0x0a (Data)
Subclass : 0x00
Protocol : 0x00
Endpoints : Control + 2
Endpoint : 0
Attributes : Control
Max Packet Size: 64
Endpoint : 2
Attributes : Bulk/OUT
Max Packet Size: 64
Endpoint : 1
Attributes : Bulk/IN
Max Packet Size: 64

USB 2 (UHCI) v1.10, v1.01 DDK, v1.01 HCD
Control, Interrupt, Bulk, Isoch, Low speed, Full speed

USB 3 (EHCI) v1.10, v1.01 DDK, v1.01 HCD
Control, Interrupt, Bulk, Full speed, High speed

2. gumstix overo cannot detect the usb device:
USB 0 (EHCI) v1.10, v1.01 DDK, v1.01 HCD
Control, Interrup, Bulk(SG), Isoch(Stream), Low speed, High speed

USB1 (MENTOR) v1.10, v1.01 DDK, v1.01 HCD
Control, Interrupt, Bulk(SG), Isoch(Stream), High speed


Or on the gumstix, there should be a deamon application which is responsible for detecting new hardware and i missed it?
Thank you.

Eric
Ericxx
Senior Member
 
Posts: 158
Joined: Mon Jun 09, 2008 1:38 pm

Postby Tim » Thu Aug 26, 2010 3:33 pm

Eric,

What parameters were use passed to io-usb (the USB drive) on the gumstix machine (do a 'pidin A' command and see how io-usb was started on both machines).

It's possible io-usb wasn't started right on the gumstix. It's also possible the gumstix doesn't support the type of usb that your device is (on the PC it seems to work in UHCI mode. On the gumstix it appears usb1 port doesn't support UHCI (only high speed, not low speed). So maybe you are just plugged in the wrong usb port.

Tim
Tim
Senior Member
 
Posts: 1419
Joined: Wed Mar 10, 2004 12:28 am

Postby Ericxx » Wed Sep 01, 2010 10:34 am

Thanks, Tim. The otg port successfully identified the usb device just like the output in the desktop.
And where should i start to get the usb device reading and writing?

Eric
Ericxx
Senior Member
 
Posts: 158
Joined: Mon Jun 09, 2008 1:38 pm

Postby Tim » Wed Sep 01, 2010 1:46 pm

Eric,

What kind of USB device is it? I see the output of usb -v above and it's not a HID device (thankfully or you'd have to fight the hid driver).

I assume you have the USB DDK? Assuming you do, take a look at the printer.c example code because it's the only one that does read + write.

Look for this line in the example (the commented out line)
// usbd_device_ident_t interest = { 0x09db, USBD_CONNECT_WILDCARD, 0x03, 0, 0 };

and replace it with this
usbd_device_ident_t interest = { 0x15d1, USBD_CONNECT_WILDCARD, 0x03, 0, 0 };

because 0x15d1 is the vendor id from your usb command (you can specify the device id instead of the WILDCARD if you want)

Then compile and run your driver. Then when you plug in your device you should get your driver called (add some printfs to the insertion/removal callback functions).

After that, everything is pretty much encoding/decoding the data to/from the device because the sample DDK code already has the resource manager framework so a user application can easily do read/writes to a device. Hopefully you have the encoding/decoding info from the vendor or Linux port etc.

Tim
Tim
Senior Member
 
Posts: 1419
Joined: Wed Mar 10, 2004 12:28 am

Postby Ericxx » Wed Sep 01, 2010 3:03 pm

oh. I have been searching for the DDK download for quite a while. But no results. Or where can i import the usb ddk to my IDE? Another problem if the 6.3.2 usb ddk can work under 6.5.0? Thanks.

Eric
Ericxx
Senior Member
 
Posts: 158
Joined: Mon Jun 09, 2008 1:38 pm

Postby Tim » Wed Sep 01, 2010 4:55 pm

Eric,

The DDK is available for download on the QNX website. That's assuming you have a development license (not a free one).

Tim
Tim
Senior Member
 
Posts: 1419
Joined: Wed Mar 10, 2004 12:28 am

Postby Ericxx » Thu Sep 02, 2010 3:56 am

Thanks. One problem is since the BSP I selected already included the usb driver and my device can be nicely detected. Then what is the reason for using USB DDK?
And can't I just use the libusbdi for my user program development?

Eric
Ericxx
Senior Member
 
Posts: 158
Joined: Mon Jun 09, 2008 1:38 pm

Postby Ericxx » Thu Sep 02, 2010 1:42 pm

I have managed to compile the devu-prn in the usb ddk, and changed the usbd_device_ident_t interest = { 0x15d1, 0, 0x02, 0, 0 }; and added some printfs in the insertion and removal as you suggested. But when trying plug in and out our usb device, the expected output didnot show.
And i'm still confused at two points: one is driver debugging just like the normal user application debug?
And how should this driver be integrated into our user application, i can put this driver into my target image, but no ideas how to use it.

Regards,
Eric
Ericxx
Senior Member
 
Posts: 158
Joined: Mon Jun 09, 2008 1:38 pm

Postby Ericxx » Thu Sep 02, 2010 1:53 pm

Well, i just found that our modified driver got stuck at SignalWaitInfo(&set, &info), but "usb -vvv" can still display the well-identified device.
Ericxx
Senior Member
 
Posts: 158
Joined: Mon Jun 09, 2008 1:38 pm

Postby Tim » Thu Sep 02, 2010 6:30 pm

Eric,

I assume you can sort out that issue on your own.

Is that modified driver you mention the one that came with your port or the devu-prn one you were experimenting with?

Tim
Tim
Senior Member
 
Posts: 1419
Joined: Wed Mar 10, 2004 12:28 am

Postby Ericxx » Fri Sep 03, 2010 2:18 am

Hi Tim, the devu-prn example. why?

Eric
Ericxx
Senior Member
 
Posts: 158
Joined: Mon Jun 09, 2008 1:38 pm

Postby Tim » Fri Sep 03, 2010 3:08 pm

Eric,

It's normal for the driver to stop there. That's where it waits forever to be terminated when the system shuts down.

Looking closer I see I made a typo in my example:

In this line

usbd_device_ident_t interest = { 0x15d1, USBD_CONNECT_WILDCARD, 0x03, 0, 0 };

the 0x03 should have been 0x02. The final 3 values in that struct (look in usr/include/sys/usbdi.h for the struct definition) are these values from the usb -vvv output:

Class : 0x02 (Communication)
Subclass : 0x00
Protocol : 0x00

Try that change and then see if your insertion/removal callbacks get called.

Tim
Tim
Senior Member
 
Posts: 1419
Joined: Wed Mar 10, 2004 12:28 am

Postby Ericxx » Fri Sep 03, 2010 4:38 pm

Thanks, Tim. Actually I have already modified the code in my previous post. But still get stuck at this function. I'm wondering how can i debug this as this is a system call.

Eric
Ericxx
Senior Member
 
Posts: 158
Joined: Mon Jun 09, 2008 1:38 pm

Postby Tim » Fri Sep 03, 2010 5:28 pm

Eric,

I don't understand. The driver is supposed to stop there and wait forever. Basically that line could have been rewritten as:

while (1);

It's only written the way it is so that the driver will nicely clean itself up.

Everything actually takes place in the insertion/removal callback functions. Those functions are invoked by a thread that is spawned inside io-usb when the usbd_connect() call is made.

So there is nothing to debug where you are currently looking because it's working as intended.

You should understand that io-usb is the *real* driver that talks to the USB hardware. What the devn-prn code does is simply tell io-usb that for that particular USB device this is who is interested in knowing when it's inserted/removed and who will read/write to it.

Tim
Tim
Senior Member
 
Posts: 1419
Joined: Wed Mar 10, 2004 12:28 am

Postby Ericxx » Sat Sep 04, 2010 12:04 pm

Hi Tim,

I modified the usbd_device_ident_t interest = { 0x15d1, USBD_CONNECT_WILDCARD, 0x02, 0x02, 0x01 }; which basically is the description for my interface0, then the insertion and removal can work; also, if i changed to the second interface paras, the driver also can work. However, if i use the previous paras (which is shown first in the usb -vvv), the driver cannot detect my device!

I changed to another webcam, this phenomenon also hold. But is it reasonable here? The two interfaces in this post, one is for communication, the other is for data, can i make the two work simultaneously?

Eric
Ericxx
Senior Member
 
Posts: 158
Joined: Mon Jun 09, 2008 1:38 pm

Next

Return to General Programming

Who is online

Users browsing this forum: No registered users and 1 guest