usb detection problem in omap3530( gumstix overo fire)

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

  1. 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

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

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

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

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

Eric,

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

Tim

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

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

Well, i just found that our modified driver got stuck at SignalWaitInfo(&set, &info), but “usb -vvv” can still display the well-identified device.

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

Hi Tim, the devu-prn example. why?

Eric

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

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

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

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

Hi Tim,

I think this problem is due to the fact that there two interfaces in this usb device, thus can be identified as one “communication” and the other “data”.

Another question is how should i issue the write or read function in the printer example, e.g. int prn_io_write( resmgr_context_t *ctp, io_write_t *msg, RESMGR_OCB_T *ocb ), could you please advise what exact paras should i pass to this write function to realize writing my specific user data?

Thanks,
Eric

Hi Eric,

This sample code creates what is known in QNX as a resource manager. You should take a look at the documentation in QNX on resource managers to understand the concept if you are not familiar with it already.

In short, your user application is not going to be calling prn_io_write(). That call is invisible to your application.

What happens is that when this code runs it creates an entry in the /dev space (which you can see by doing a ‘ls /dev’ command). It’s going to work similar to how serial data works in that an ‘ls /dev’ command will show ser1 and ser2 if you have 2 serial ports.

Anyway, what your user application does is really simple. Lets suppose a command to the camera is the character sequence 0x01,0x02,0x03,0x0d;

int fd;
int length
char myData[80]
fd = open ("/dev/prn1", rw); // Opens the resource manager assuming it’s called prn1
myData[0] = 0x01;
myData[1] = 0x02;
myData[2] = 0x03;
myData[3] = 0x04;
length = 4;
write(fd, myData, length); // writes to the resource manager

And that’s it. The sequence is sent to the printer code which in turn sends to over the USB to the camera.

That’s why I said the printer code is dumb and doesn’t know anything about the actual device (camera) commands. It’s only job is to pass data to/from a USB device. As long as your user app knows how to format the data you are good to go.

Incidentally, it’s perfectly fine to create 2 of those printer applications. One for the data and one for the commands. Then in the /dev directory you can have /dev/prnCommand and /dev/prnData. Then your user app can open the appropriate one and read/write to it.

Tim

Hello, Tim

I have managed to generate /dev/prn1, and successfully got a valid fd nubmer. But i came across with the following error when tried to issue the write function as you suggested above:

“Process 8200 (devu-prn) terminated SIGSEGV code=1 fltno=11 ip=78008adc(libusbdi.
so.2@usbd_io+0x20) mapaddr=00008adc. ref=00000008”

Please kindly suggest. Thank you.
Eric

Eric,

Ouch. Something crashed somewhere.

Assuming you are running dumper and that you compiled devu-prn with debug information you can debug the core dump (in /var/dumps). That should let you see where things crashed.

Alternatively, you can run devu-prn in the debugger directly, let it go into the infinite wait, start your user app and wait for the crash in the debugger and then see why it crashed.

Tim

Eric,

One thing I forgot to ask in my last post.

Are you running devu-prn as root? I believe it must be run as root to function properly.

Tim