I'm facing issues when communicating with devices over USB hub. When enumerating devices directly to host port, it does work, some devices over usb hub have issues.
Setup: STM32F103C8 - MAX3421E - LUFA (usb stack) (ported to MAX3421E (host) and STM32F103C8T6 (device)) - USB Full-Speed setup
Scenario:
When I attach device directly to host, I don't experience any issues enumerating almost all (some devices seems to be faulty and have weird/nonstandard behavior) devices. But when I try to enumerate over usb hub, devices starts to behave very strangely. I'm receiving much more NAK's from devices than when connected directly to host. Some devices are able to return Device Descriptor, but retrieving Configuration Descriptor fail. Some devices return Toggle Error after several NAK's, this could be remedied so far by delaying retry IN token. Also there is different behavior of devices when connected over different hubs. I.e. one device has no problems when connected to HUB1, but have issues when connected to HUB2. Then I have HUB3 (7 port) which internally acts as HUB in HUB. On this HUB3 device working fine on port behind secondary internal hub, but not on primary ports exposed over "root" hub.
I'm in suspicion that hub's TT could be somehow interfering with usb communication, but according to information I have found, TT should not be enabled under Full-Speed setup.
I have checked (many times) that I'm setting correct device address assigned during SetAddress phase (which is proved by returning Device Descriptor). When I step debug it seems that I can get Configuration Descriptor also, but while in normal system run, it isn't retrieved, but only over hub.
Does anyone has any ideas, what to look after? I've run out of ideas here after week of trying to find a root cause.
Thanks
so...
- as usual after searching for root cause, solution after days of trying comes naturally after asking on somewhere (this is hapenning to me always, but I do try prior asking always)
- when using hubs, make sure you don't suspend SOF generation during control transfers. LUFA just resume bus inside control transfer routines, so make sure you don"t stops and reenable SOF within (my fault as I'm using ported version to MAX)
- if you have tight main loop make sure you don"t reinitialize usb transfer without completion of previous try, but if you do so, check you don't owerwrite data which haven"t been processed yet fully (especially when using interrupt-driven transfer complete processing) [things seems to work when you have quite some debug output, as it delay that time critical transfers]
Enumeration over hub isuues are now second to none. Small glitches are subject for tweaking.
Unfortunately as I was in question for electrical issues, I had to unsolder usb host shield and soldered another one, which in light of new information seems unneeded. Nevermind, I have trained my soldering skills.
Related
I have a program written in Visual Basic (.NET Framework 3.0) that communicates with a power supply via a D2XX driver (over COM3) and a pump via a VCP driver (over COM2). Currently, if both USB devices are plugged in when I start the program, it tries to communicate with the pump, (COM2) when trying to communicate with the power supply (COM3). I found a temporary solution to this issue by only have the power supply connected when starting the program. Then I initialize communication with the power supply, and afterwards plug in the pump; this allows the program to communicate with both separately for the rest of the time running the program. But this process is tedious and I am hoping there is an alternative solution where I can keep both units connected via USB and the computer communicates separately. What is confusing is that this communication issue was not always the case, a week ago it worked without having to disconnect the pump (all drivers are updated, and on the device manager they are listed as their respective COM ports as well) ; I am struggling to find some correlation between what is the underlying issue.
I tried to delete other hidden additional COM ports. I made sure all drivers were updated. When the pump is communicating via the same port as the power supply, and then I try to communicate with the pump, I receive this error:
System.UnauthorizedAccessException
HResult=0x80070005
Message=Access to the port 'COM2' is denied.
Source=<Cannot evaluate the exception source>
StackTrace:
<Cannot evaluate the exception stack trace>
But again, If I start the program with only the power supply plugged in and initialize communication with the power supply, and THEN plug in the pump, this issue is evaded. I hope someone can give some sort of direction at all troubleshooting this issue because I am completely stumped. Thank you!
Most likely your program implicitly relied on the correct enumeration order. If you use devices with an FTDI product with internal flash or with dedicated eeprom, you may be lucky: Many can configured via FT_PROG to be visible only for D2XX and not as VCP. This way you can avoid the problem. Alternatively, you can try to modify your program so that it accesses D2XX first. Make sure to filter out the correct device using device informations. E.g. the serial number or the VID:PID if the device manufacturer has made the effort to aquire its own IDs. Check 3.4 FT_GetDeviceInfoList of D2XX Programmer's Guide for details.
I'm playing around with an old Trackball I purchased from Sparkfun. My trackball powers on, but it doesn't actually work. All the lights flash, and it indicates that I've left and right clicked, but the mouse on my screen does nothing.
I want to monitor the input values of the trackball across a USB port so I can track down the problem. I've looked for code I can run on Netbeans, but came up empty handed.
Please advise
You didn't specified what OS are you using. You need dedicated driver for this device. In case of Linux you would need to write your own driver for the kernel. But first you need to have specification of protocol which this device is using over usb and also usb protocol itself. It is quite sophisticated task to do...
In case of Windows there are some programs for dumping transmission between usb host (PC) and device (trackball), but at the moment I can't give you any name of such program. In case of Linux you can dump the transmission using tcpdump or wireshark commands.
I encounter a problem when I'm trying to use a Ubuntu laptop computer to connect to two Sony A6000 through WiFi in the same time.
On that laptop there are two WiFi adapters, one is embedded (say, Wifi-A) and the other is an Asus USB-N13 ProN USB
dongle (say, Wifi-B).
Using Sony Camera Remote API I can successfully control these two A6000 (say, A6000-A & A6000-B)
through these two Wifi adapters, provided only one camera is connected a time. For example, either using Wifi-A to control to
A6000-A or A6000-B, or using Wifi-B to control A6000-A or A6000-B, will work.
I think this proves both the cameras and Wifi adapters hardware function correctly, and any combination of Wifi adapter and
camera works fine, too.
However, it will be different if I try to connect and control both cameras in the same time. The connection to both cameras
is OK (though sometimes not very smooth), but controlling them is not.
Here is a list of the experiment steps:
Wifi-B connects to A6000-B. Then Wifi-B gets IP address 192.168.122.166
Wifi-A connects to A6000-A. Then Wifi-A gets IP address 192.168.122.165
Send M-SEARCH request to Wifi-A and get response from A6000-A. Then get
Device Description XML file from A6000-A successfully.
Send M-SEARCH request to Wifi-B and never get response
I'm wondering if such configuration (One laptop + two Wifi adapter + two A6000) violates any design consideration
of A6000? For example, because both cameras use the same IP address 192.168.122.1 for themselves?
I'll appreciate if any one could comment on this issue.
Thanks in advance!
Xavier
After doing experiments for many days, I'm sure this symptom is caused by the IP address conflict (both of them are 192.168.122.1) of these two A6000.
As I can't find a way to change them, my optimal solution under such configuration (one laptop + two Wifi adapter + two A6000) is to make use of Linux Network Namespaces. Moving Wifi-B to a new Network Namespace does solve this issue, because every Network Namespace has its own network stack. Now I can freely access both of these A6000 from my laptop.
I hope this answer is helpful to anyone who encounters a similar problem.
There isn't any design consideration that would block this from working. Unfortunately we cannot offer any other troubleshooting suggestions.
Since we plan to use MTP (Media Transfer Protocol) for your next device, we evaluate the use of MTP as replacement for the current (unstable) USB drivers in the current released device.
The limitation on this device is, that its processor (Strong Arm) supports only up to 3 EndPoints:
"Serial port 0 is a universal serial bus device controller (UDC) that supports three endpoints and can operate half-duplex at a baud rate of 12 Mbps (slave only, not a host or hub controller)."
But according to the specification, MTP needs at least 4 endpoints (from the PTP spec):
"The device shall contain at least four endpoints: default, Data-In, Data-Out, and an Interrupt endpoint."
Now the question: Can we just skip the interrupt endpoint on the device? I know that it violates the specification - but what happens if we do?
From our current evaluation software I can see the following scenarios:
The 'space available' is not updated - the user will see that there is 100Mb of free memory, but placing a 1Mb file gives the error "Not Enough Memory"
Non-host driven actions are not visible on the host (so when on the device files are deleted, created or moved, the connected host does not know about it)
If we can live with it, is it advisable to implement it this way?
UPDATE: Damn... when I tested it last time, I ve just removed the code for interrupt-EP data transmission. Now I also removed the endpoint definition (I do not create the endpoint anymore) and from this point the MTP connection couldn't be established any more :(
It seems that the windows driver (wpd) requires the interrupt endpoint - even if it's not used. Bad luck...
Has anyone an idea, whether and how to get MTP working with 3 endpoints?
Finally I got an answer from Microsoft:
The 3-endpoints setup is not supported.
The interrupt endpoint is required so that the driver can receive MTP events from the device. These events are a notification mechanism that the driver relies on to relay events to applications (e.g. when an object is created, updated, or removed).
If your device does nothing with the endpoint (i.e. send no events), applications such as Explorer will not behave correctly whenever objects on your device are changed.
So we buried our plans... :(
I am trying to access an USB HID device under Ubuntu(kernel-3.0). I want to write a program which could notify me whenever an USB device is attached to the bus i.e is there any event generated whenever an USB device is plugged in which I can monitor. I have looked into DBus and HAL without any success. But I don't want linux to load its current modules(USBHID and HID) when the device is plugged in. I also want to ask if the mentioned modules are also the device drivers used for HID devices.
My sole purpose is to run a script whenever an USB device is plugged into the bus which will indirectly call the above mentioned modules.
I am writing my code in C. I am quite new to linux. So it would be of great help if anyone could point me in the right direction.
Thanks..
The UDisks deamon will send the D-Bus signal "DeviceAdded" when a USB drive is inserted, and probably another "DeviceAdded" for each partition on the drive. If you have automount you would also get a "DeviceChanged" signal when the partition(s) are mounted. You can then query the UDisks interface, as well as individual devices about their properties, for example. You can find more info on the UDisks interface here: http://hal.freedesktop.org/docs/udisks/UDisks.html
One way to get more familiar with what goes on with block devices (or whatever) on D-Bus, is to install and use D-Feet to inspect the bus. UDisks appear on the System bus. You can see what is there and inspect the properties for individual devices as well as the UDisks interface itself.
Another way, which would also allow you to see what signals are transmitted on the bus, is to run dbus-monitor from the command line.