Skip navigation.
Home
The QNX Community Portal

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.

Postby Ericxx » Mon Sep 06, 2010 10:50 am

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
Ericxx
Senior Member
 
Posts: 158
Joined: Mon Jun 09, 2008 1:38 pm

Postby Tim » Tue Sep 07, 2010 6:03 pm

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
Tim
Senior Member
 
Posts: 1393
Joined: Wed Mar 10, 2004 12:28 am

Postby Ericxx » Wed Sep 08, 2010 9:01 am

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
Ericxx
Senior Member
 
Posts: 158
Joined: Mon Jun 09, 2008 1:38 pm

Postby Tim » Wed Sep 08, 2010 2:55 pm

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
Tim
Senior Member
 
Posts: 1393
Joined: Wed Mar 10, 2004 12:28 am

Postby Tim » Thu Sep 09, 2010 2:11 pm

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
Tim
Senior Member
 
Posts: 1393
Joined: Wed Mar 10, 2004 12:28 am

Postby Ericxx » Mon Sep 13, 2010 2:09 pm

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?
Ericxx
Senior Member
 
Posts: 158
Joined: Mon Jun 09, 2008 1:38 pm

Postby Tim » Mon Sep 20, 2010 6:36 pm

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:

Code: Select all
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
Tim
Senior Member
 
Posts: 1393
Joined: Wed Mar 10, 2004 12:28 am

Postby Ericxx » Tue Sep 21, 2010 1:30 am

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
Ericxx
Senior Member
 
Posts: 158
Joined: Mon Jun 09, 2008 1:38 pm

Postby Tim » Tue Sep 21, 2010 2:44 pm

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
Tim
Senior Member
 
Posts: 1393
Joined: Wed Mar 10, 2004 12:28 am

Postby Ericxx » Wed Sep 22, 2010 10:40 am

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
Ericxx
Senior Member
 
Posts: 158
Joined: Mon Jun 09, 2008 1:38 pm

Postby Tim » Wed Sep 22, 2010 1:39 pm

Eric,

Ericxx wrote: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.


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.

Ericxx wrote: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()?


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
Tim
Senior Member
 
Posts: 1393
Joined: Wed Mar 10, 2004 12:28 am

Postby Ericxx » Mon Sep 27, 2010 11:47 am

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
Ericxx
Senior Member
 
Posts: 158
Joined: Mon Jun 09, 2008 1:38 pm

Postby Tim » Mon Sep 27, 2010 1:42 pm

Eric,

http://www.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
Tim
Senior Member
 
Posts: 1393
Joined: Wed Mar 10, 2004 12:28 am

Previous

Return to General Programming

Who is online

Users browsing this forum: Yahoo [Bot] and 2 guests