Re: USB HUB issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 16 Apr 2011, Marcel wrote:

> Hi,
> 
> I've got and issue probably with USB 2.0 split transactions, although I'm not 
> sure of that yet. The situation is a little complex.
> 
> What I have in hardware is this :
> 
> PC ---> Atmel G45 MCU ---> HUB ---> 2 devices.
> 
> All connection are USB. The 2 devices are full speed and all other USB 
> connections are high speed. Whether I connect one or two devices doesn't 
> matter for my issue.

You are using the Atmel G45 in two different roles here, right?  It 
acts as a host when communicating with the hub and the two devices, and 
it acts as a device when communicating with the PC.

> When I run a program on the Atmel G45 to address the 2 devices it runs well.
> What I do is :
> 1) I open both devices
> 2) I write a command to both devices
> 3) I read something from both devices
> 4) I close both devices
> This runs basically in a continuous loop and never fails.
> 
> What I need however is actions to be done from the PC.
> I send the command for writing to the 2 devices from the PC, the Atmel G45  
> than sends it to the 2 devices and reads data from the devices.
> I than issue a read from the PC and should get the results from the 2 devices.
> 
> This works but is not reliable. Sometimes I experience the HUB being 
> disconnected and I don't have a clue yet why it gets disconnected. It doesn't 
> do that when running a program directly on the Atmel G45. 
> The HUB in use is this one :
> http://www.mouser.com/catalog/specsheets/2514.pdf
> 
> The disconnect occurs after data has been send from the Atmel G45 to the PC 
> but I have no clue why that could influence the HUB behaviour as this action is 
> on the USB device side of the Atmel G45.
> This last data arrives well at the PC side. The HUB than enumerates again and 
> it can be used again (but is not useful to me).

What happens if you avoid communicating between the Atmel G45 and the 
devices and instead always send back zeros to the PC?  Does the hub 
still disconnect?

> The HUB and my Atmel have both external power connected. The devices use about 
> 60mA each. Not using external power for the HUB or the Atmel causes the same 
> behavior.
> 
> I used another HUB which doesn't do high speed split transactions but uses 
> full speed connection to my devices and this seems to work a lot better. In 
> fact it ran all night without errors. The other HUB doesn't last a single 
> minute.
> 
> As mentioned, running a program directly on the Atmel G45 works fine, but as 
> soon as I include the PC connection things start to behave differently for 
> different types of HUBs.

This sounds like a hardware problem within the Atmel G45.  Somehow use
of the device port interferes with the high-speed operation of the host
port.  I doubt very much that this is related to the use of split
transactions -- I bet you would see the same effect if the two devices
ran at high speed.

> I'm wondering what happens when I connect USB to my PC and why that influences 
> the behavior of the HUB. 

Probably it influences the behavior of the Atmel G45, not the behavior 
of the hub.

> Somehow it all looks like some major timing issues,

Timing issues don't cause disconnects; they have different symptoms 
(-71 errors, for example).

>  but I wonder why the HUB 
> performs well when I run a program on the Atmel G45 and don't use the USB 
> device connection to the PC. On the Atmel I use a 2.6.33 kernel.
> 
> Another strange phenomenon is that sometimes the HUB can't be enumerated, but 
> when I than disconnect the USB device port, it suddenly can enumerate. 

Clearly that has nothing to do with split transactions.

> Any ideas on how to find the root cause of this issue are welcome.  

Most likely the root cause is a hardware bug in the Atmel G45.  
However the only way to prove this would be to replace the G45 with a
different kind of system.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux