usb detection problem in omap3530( gumstix overo fire)

Hi Tim,

I have managed to send data from the gumstix usb OTG port to the laser scanner. The laser scanner can be turned on and off by the corresponding controlling data. However, I failed to read any data replied from the laser scanner. The “read” function always returns -1. My setup for the USB configuration now is usbd_device_ident_t interest = { 0x15d1, 0x0000, 0x0a, 0x00, 0x00 }, which means the bulk-transfer interface is used (plz refer to the following “usb -vvv” response)

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

Does bulk-transfer have any limitations such as unidirectional transfer?

Again, if I use usbd_device_ident_t interest = { 0x15d1, 0x0000, 0x02, 0x02, 0x01 } as the configuration (interface 0/0), “read” and “write” will both cause the fatal error I mentioned before and the driver will be terminated. Any ideas?

Hi Eric,

I was on vacation last week.

Congrats on getting the write portion working.

AFAIK, bulk transfer is bi-directional (assuming the device supports it). Your device seems to do that:

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 

As I see a Bulk/OUT and a Bulk/IN endpoint.

In the prn_parse_descriptiors() routine you’ll see a line that says:

scan = PRN_CONTROL_EP | PRN_BULKOUT_EP.

Did you add a PRN_BULKIN_EP to this indicating you are looking for a bulk in interface? Then below in the same routine in the USB_ATTRIB_BULK case if you put a print statement in that case, do you see endpoint->out AND endpoint->in cases found by the code which would indicate you are attaching for read/write?

Assuming you’ve done all that and it still doesn’t work then my question to you is, what makes you expect the laser device should be sending data to you? In other words, are you sure there isn’t some command you need to send the device to tell it you send you data (a data request) or do you have reason to believe it should just stream data to you on it’s own when doing scanning?

It’s hard for me to know what the problem is at this point because I’ve never used this device. Where are you getting the original driver commands from? Linux? Was there any special command that had to be sent to request data etc. What you really need at this point is a data-flow diagram of how the device sends data to the PC including any initialization commands that need to be sent beyond turning the device on/off.

Tim

So glad you are back, Tim. I am still suffering from the read operation. Yes, we have added PRN_BULKIN_EP to the scan variable to search for an interface with both bulk/in and bulk/out. And the program execution reached to prn_io_read() where we get stuck. And may i know where the data is exactly read from the buffer, from resmgr_msgwrite( ctp, ibuf, alen, pos )?

For this usb device, the operation mechanism should be simple. We only need to send another three-byte command to request the data. And is there any better way that we can debug this device in a better way?

Thanks,
Eric

Hi Eric,

So you can positively confirm (via a print message) that you attach to the BULK_IN_EP? In the parse_descriptors() call do you see anything other end points attached besides BULK (like ATTRIB_INTERRUPT for example).

I am not sure why you’d be stuck in prn_io_read(). I would have thought you’d call prn_io() which calls prn_bulk_wait() to wait for actual data (and this is where I’d expect you to end up waiting).

I do have another question. Do you know if the device normally sends data in BULK mode or in the Communication mode (Class 0x02 in the usb command). Maybe you need to send a command to the device to tell it to use bulk mode to transfer data as it may be trying to use the other mode.

Tim

Hi Tim,

Now i am debugging the driver just an application program, but one runs in a deamon mode to be activated anytime once the usb device is inserted.

May I say that as long as the identification in parse_descriptors() is correct then the remaining read/write operations are handled by resource manager and thus should be no problem. In other words, we as the developer should not touch the code in prn_io()?

Eric

Eric,

Understood. But you can still put printf’s in the daemon code that will print to the console when certain points in the program are reached. You can use those printf’s to make sure things are doing what you expect or that code blocks are being reached, endpoint descriptors are being found etc.

Yes. Once you get communication working in both directions you’ll never need to touch any of that code again. Right now you have the outgoing direction working so it’s just a matter of getting the incoming direction working.

I expect you need to tell your device to work in bulk mode as it may be working in Communication mode by default (it makes better use of USB bus)

Tim

Hi Tim,

We changed the usb to serial with devc-serusb, and the device can work fine now. One point is the the original usb speed is now limited by the UART speed? As there is a baudrate option in the devc-serusb driver. Thanks.

Eric

Eric,

qnx.com/developers/docs/6.4. … erusb.html

The -b option sets the baud rate. By default it’s 56K.

Since this is a BULK driver and that’s what you were attempting to write, perhaps you might be able to get QNX to give you the source to this driver. Then you’d be able to modify it to take the serial component out entirely and get the pure USB speed.

Tim