usb driver problem

QNX DEVELOPERS Realtime and Embedded
1

Hi all,
I have a problem on establishing USB connection between a x86 host running QNX Neutrino6.3.2 and a micro-controller device (8051 based Silabs F340 board) running a specific firmware to communicate with the host. I implemented a device specific QNX driver for the USB connectivity using usb-io, and I use this driver as an interface between the host application and the Silabs board firmware in order to exchange data. I used below host platforms for testing:

  1. QNX Neutrino on VMWare5.5 running on Windows XP (installed on a PC with CoreDuo2 processors)

  2. QNX Neutrino on Lippert Cool Front Runner PC104 board (QNX is not installed on the compact flash of the board yet, it runs on a Seagate harddisk connected to the board via IDE slot)

In both platforms:

  • firstly the QNX driver (on Momentics) is cross-compiled to the target QNX platform (host PC/or Lippert board) over Ethernet via QConn
  • then, the USB cable is inserted to the USB port of the QNX platform
  • and finally the host application is started on the QNX platform for data exchange

In the first platform(PC), the Silabs device is successfully detected upon insertion, and the host application successfully exchanges data with the device.
However, in the second platform(Lippert board), although the device is detected and the host application is started (hence probe,open functions of the driver are executed), the data exchange fails(timeouts) with a USBD_STATUS_DEV_NOANSWER error upon urb submission. When I debugged the firmware, I noticed that although its execution is interrupted with interrupts from the QNX platform, it doesn’t receive any data.

Has anyone got any idea on why such an application might fail on this second platform(Lippert board) although it perfectly runs on the first one? Where do you think I should concentrate to find the bug here?

Thanks…

Cihan Ozturk

2

Chian,

Can you do a ‘usb -v’ command on both platforms.

Then check your start up of io-usb on both platforms and make sure you are starting io-usb correctly based on the physical usb host controller hardware.

I suspect that the PC104 is supporting usb 1.0 and the VMWare is supporting usb 2.0. Since 1.0 is much slower the response might time out if io-usb isn’t starting with the right arguments.

Tim

3

Thank you very much for being interested in Tim…
Well, actually PC104 supports USB 1.1, and that should be enough for our communication since the USB module of Silabs device communicates at Full Speed, which I should have mentioned in the first message I guess. And I might have misled you about the timeout event: what actually happens is that the device never responds the urb (no handshake is sent back), and I think the device never receives any valid data from the host as I mentioned in the first message (no data observed while debugging firmware, only its OUT endpoint interrupted).
Timeout is a result of a parameter I give to the urb submission function, if I give INFINITY, it never times out.
Lastly I am not sure about what you mean by “starting io-usb correctly based on the physical usb host controller hardware”. Well I am sure io-usb starts(otherwise probing would fail as well), but not sure about how I can check it starts “correctly”…

4

Chainz,

When io-usb is started it must be told what kind of usb hardware controller it expects to find. If you start it with the wrong kind, it won’t communicate properly with usb devices. You might also want to check BIOS settings on the PC104 board to make sure that the usb controller is actually turned on.

If you do a ‘use io-usb’ you’ll see the 3 kinds of controllers that are supported and which options you must pass to support which controllers.

If you do a ‘pidin A | grep io-usb’ you’ll see which controllers io-usb was started with.

I’d suggest running those commands on the PC104 board vs the VMWare version to see if io-usb is misconfigured. I suspect the PC104 board may be started incorrectly. Can you then post the results of running those commands here.

Can you also do a ‘usb -v’ on both platforms and post the result here. If io-usb is configured/started correctly that command should list your usb device.

Lastly which version of QNX are you using.

Tim

5

Hi Tim,
I prepared the log messages you asked for, here they are.
Firstly when I run the commands at user level, I get the following error messages(in both VMWare and Lippert card):

[size=75][color=darkred]$ who am i
cihan ttyp1 7 Apr 21:09
$ pidin A |grep io-usb
4101 io-usb -duhci -dohci -dehci
4102 io-hid -d ps2ser kbd:kbddev:ps2mouse:mousedev -d usb /dev/io-usb/io-usb
2002987 grep io-usb
$ usb -v
/bin/sh: usb: not found
$ use io-usb
‘io-usb’ is not an executable file in PATH: ‘/bin:/usr/bin:/usr/photon/bin:/usr/p
hoton/appbuilder:/opt/X11R6/bin:/usr/X11R6/bin:/usr/local/bin:/opt/bin:/usr/qnx63
2/host/qnx6/x86/usr/bin:/usr/qnx632/host/qnx6/x86/usr/sbin:/usr/qnx632/host/qnx6/
x86/sbin:/usr/qnx632/host/qnx6/x86/bin:/usr/qnx632/host/qnx6/x86/usr/photon/appbu
ilder:/usr/local/bin:/opt/bin:/usr/qnx632/host/qnx6/x86/usr/bin:/usr/qnx632/host/
qnx6/x86/usr/sbin:/usr/qnx632/host/qnx6/x86/sbin:/usr/qnx632/host/qnx6/x86/bin:/u
sr/qnx632/host/qnx6/x86/usr/photon/appbuilder’.
$[/size]

I already run the test application as root, therefore I switched to superuser. Afterwards I ran the commands as the root, this time, there was no problem. Here is the log messages from Lipperd card before inserting the Silabs device to USB port:

[size=75][color=darkred]
usb -v:
USB 0 (OHCI) v1.10, v1.01 DDK, v1.01 HCD
Control, Interrupt, Bulk, Isoch, Low speed, Full speed

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

pidin A | grep io-usb:

4101 io-usb -duhci -dohci -dehci
4102 io-hid -d ps2ser kbd:kbddev:ps2mouse:mousedev -d usb /dev/io-usb/io-usb

1642541 grep io-usb
[/size]

After inserting the device usb -v gives:
[size=75][color=darkred]
USB 0 (OHCI) v1.10, v1.01 DDK, v1.01 HCD
Control, Interrupt, Bulk, Isoch, Low speed, Full speed

Device Address : 1
Upstream Host Controller : 0
Upstream Device Address : 0
Upstream Port : 1
Upstream Port Speed : Full
Vendor : 0x10c4
Product : 0x0003
Device Release : r0.00
Class : 0x00 (Independant per interface)
Max PacketSize0 : 64
Configurations : 1
Configuration : 1
Attributes : 0x80 (Bus-powered)
Max Power : 30 mA

USB 1 (OHCI) v1.10, v1.01 DDK, v1.01 HCD
Control, Interrupt, Bulk, Isoch, Low speed, Full speed
[/size]

And here is the result of running ls /dev | grep usb:
[size=75][color=darkred]
io-usb
usb_dev0
[/size]
Since the name of Silabs device is defined as usb_dev0, I guess all these logs mean that usb controller is properly turned on the grounds that the
device is successfully detected.

Here are the logs from VMWAre. Before inserting the device:
[size=75][color=darkred]
usb -v:
USB 0 (UHCI) v1.10, v1.01 DDK, v1.01 HCD
Control, Interrupt, Bulk, Isoch, Low speed, Full speed

pidin A | grep io-usb:
4101 io-usb -duhci -dohci -dehci
4102 io-hid -d ps2ser kbd:kbddev:ps2mouse:mousedev -d usb /dev/io-usb/io-usb
692263 grep io-usb
[/size]

After inserting the device usb -v returns :
[size=75][color=darkred]
USB 0 (UHCI) v1.10, v1.01 DDK, v1.01 HCD
Control, Interrupt, Bulk, Isoch, Low speed, Full speed

Device Address : 1
Upstream Host Controller : 0
Upstream Device Address : 0
Upstream Port : 0
Upstream Port Speed : Full
Vendor : 0x10c4
Product : 0x0003
Device Release : r0.00
Class : 0x00 (Independant per interface)
Max PacketSize0 : 64
Configurations : 1
Configuration : 1
Attributes : 0x80 (Bus-powered)
Max Power : 30 mA
[/size]
So as you see, the only difference is that VMWare uses UHCI while the Lippert card uses OHCI. Do you think this might be the reason behind
the failure? If so, is there a way to remove the OHCI from the Lippert card and use UHCI instead?
Lastly, I’m using QNX Neutrino 6.3.2.
Thank very much…

6

Chainz,

I would suspect that the problem is indeed related to the UHCI (Intel spec) vs OHCI (windows spec).

The device you are trying to talk to may not support OHCI spec (you’d have to contact the manufacturer to find out for sure).

I don’t know anything about the Lippert card. Is there any kind of BIOS on it where you might be able to configure the USB controller on the card? You may need to contact Lippert to ask them about the USB controller and if it can support UHCI.

You can also try one quick experiment before checking the BIOS / calling the manufacturer. Try the following (as root) on the Lippert Card system (if you have a USB keyboard/mouse connected to the card you can’t do this since you’ll lose the keyboard/mouse so I hope you are using Momentics or have a PS2 keyobard/mouse).

slay io-usb (kills io-usb)
io-usb -duhci (restarts it only looking for a uhci controller)
usb -v

If you are lucky, the USB controller on the Lippert card can also support UHCI and you’ll see the USB controller as a UHCI controller. If you are not lucky usb -v will report nothing found.

Tim

7

I recomend you upgrade your VMWARE because I couldn’t run any USB stuff under vmware 5.x. After I upgraded to the latest Vmware all my USB problem went a way.

8

Well I’m not very lucky, the trick you recommended doesn’t solve the problem, after executing the commands, usb -v doesn’t display anything.
I couldn’t find any useful information in the data-sheet of the card but it most probably doesn’t support UHCI. Neither there is anything to modify its host controller to UHCI in its BIOS.
I looked at the data-sheet of the Silabs device, but it also doesn’t tell anything about the host controllers it supports.
Anyway, I will try to contact both manufacturers and return back any information I obtain.
Thanks very much…
(By the way, I’m trying to work this application on the Lippert card, the VMWare was just a test platform. Therefore upgrading it will not do any help to me.)

9

We couldn’t obtain any information on whether the Lippert board support for UHCI is possible or not, but found a solution for our problem. The problem was due to some implementation problems in the firmware, and the solution is USB related, not directly related to QNX.
The endpoints of Silabs device have obvious sizes, specified in its datasheet. In the device firmware, we previously set the endpoint->wMaxPacketSize variable to max endpoint buffer size, ie. 256 bytes for Endpoint3. However, the max payload size of a bulk urb for Full Speed transmission is defined as 64 bytes in USB Spec2.0. The UHCI controller most probably splitted any urb the driver sent which is larger than this limit into multiple packets and sent them within a single transaction. So we did not notice any problems with our Linux driver, which used UHCI. I guess that the firmware didnot fail because although endpoint->wMaxPacketSize was set to some value larget than 64, firmware always received max 64 byte packets as a benefit of UHCI. However, when we ported our platform to QNX running on Lippert with OHCI support, the firmware probably started receiving data packets larger than 64bytes, and the problems began.
As a solution:

  • we firstly set endpoint->wMaxPacketSize to 64 in firmware
  • we updated the firmware so that any transaction that was larger than 64 bytes was manually split into 64 byte chunks and sent to upper layers of firmware one after another
    Thanks all for your help…