Hi Alan, > > 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. Correct. > > 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? I just tried this and indeed the HUB does disconnect even if there's no communication with the 2 devices. So most certainly something goes wrong in the G45's device side :-( > > 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 hope not........ Strange enough this behavior is different for another HUB, which ran perfectly all night (over 1 miljon transactions). Anyway, I already figured out that the host side works perfect when just running software on the G45. It does make sense to check out what the device side is doing. > > 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). OK. > > 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. I figured that out as well by now. I fully trust the host side is working correctly by now. It must be either something in atmel_usba_udc or an hardware issue. I will dig further and see if I can find something with my analyzer. > > 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. That would be very hard to do for me. It looks like I need to dig more into what it really happening, but it I can't find anything in the device side code, I probably have to ask Atmel for some help on this. Best regards, Marcel -- 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
