UHCI Port reset

[Sauro]

HI,
I have a strange problem with a usb device
I'm a assembly programmer , these days I was writing a driver for the  full/low speed devices. (UHCI)
I own 10 devices, all work fine except for one device, which shows problems when I do a port reset. I use the classic sequence:
Wait the device is connected
Wait 400ms (Debounce for my USB Bluetooth device)
Port Reset 10ms
Recovery 10ms
Enable port.
Get Descriptor and so on ...
Ok, this sequence is perfect with all the devices, but one in particular (USB Mass Storage) only works if I do not do a Port Reset.
If I do a port reset, the device dies and I do not know how to resurrect :-)
This device has a red LED, which turns off after a port reset and the device no longer works.
Without a port reset, the device works perfectly.
Any ideas ?

[Bret]

According to section 10.2.8.1 of the USB 1.1 specification:

Section 7.1.7.3 describes the requirements of a hub to ensure all upstream resume attempts are overpowered with a long reset downstream. Root hubs may provide an aggregate reset period of at least 50ms. If the reset duration is controlled in hardware and the hardware timer is <50ms, the USB System can issue several consecutive resets to accumulate a sufficiently long reset to the device.

Don't know if it's your problem or not, but a reset on a root hub should last at least 50 ms, not just 10.  Here's the sequence I use, and haven't had a problem with devices not resetting properly (but maybe I just haven't run across the correct device yet):

Clear Port Enable Bit
Wait 100 microseconds
Verify Port Enable Bit is Clear, Exit if not
Set Port Reset Bit
Wait 100 microseconds
Verify Port Reset Bit is Set, Exit if not
Wait a minimum of 50 milliseconds
Clear Port Reset Bit
Wait 100 microseconds
Verify Port Reset Bit is Clear, Exit if not
Verify Port Connect bit is still Set, Exit if not
Set Port Enable Bit
Wait 100 microseconds
Verify Port Enable Bit is Set, Exit if not
Wait 10 milliseconds
Continue with Enumeration Process

[Sauro]

Hi,
Thanks for your reply.
I'm sorry but your code does not work with any of my devices

Clear Port Enable Bit
Wait 100 microseconds
Verify Port Enable Bit is Clear, Exit if not
Set Port Reset Bit
Wait 100 microseconds
Verify Port Reset Bit is Set, Exit if not
Wait a minimum of 50 milliseconds
Clear Port Reset Bit
Wait 100 microseconds
Verify Port Reset Bit is Clear, Exit if not
Verify Port Connect bit is still Set, Exit if not
Set Port Enable Bit
Wait 100 microseconds
Verify Port Enable Bit is Set, Exit if not                   ; EXIT ALWAYS HERE
Wait 10 milliseconds
Continue with Enumeration Process

After I fix the part of your code, my 10 devices have started to work except the famous device that does not like the Port Reset.
I suspect that there is another way to reset the ports,
seems that the BIOS and Windows knows very well how to do it

[Bret]

There is no other way to reset a specific port on a UHCI host, but maybe the timings don't work correctly with your hardware for some reason.  Next thing I would try is experimenting with some delays between the reset stop and port enable and port enable verification.  Doesn't it seem at least a little bit strange to you that you can't even verify that the port enable bit is set?

[Sauro]

Ok,
Now it works 
I did not think that the Host Controller must be in RUN State to Reset the Port,
at least with regard to this device....
I'm still not entirely convinced, but now it works.
But if the controller must be in Run State, why the other 10 devices, i could do a Reset  with the Host Controller in Stop State?
Why, with the Host Controller in Stop State, and without Reset,the device worked?

[Bret]

What do you mean "the device worked" when the host was stopped?  That's not possible, since no framing / timing could be generated.

Were you not starting the host until after the port reset, but before you started downloading the descriptors?

The "normal" state for an unused port is to be running, but disabled.  After a device connection is detected, the port is reset and enabled.

[Sauro]

What do you mean "the device worked" when the host was stopped?  That's not possible, since no framing / timing could be generated.

Yes, I'm not so Stupid 

Were you not starting the host until after the port reset, but before you started downloading the descriptors?

Yes, My First Tets was to  Enable the HC Run (bit 0 = 1) after Reset 

The "normal" state for an unused port is to be running, but disabled.  After a device connection is detected, the port is reset and enabled.

Now I have learned, 
I do not understand why the port does not reset if the controller is in the stopped state only with one device, while the other 10 devices works well ?

[Bret]

Since the host wasn't running when you issued the reset, it's hard to say what kinds of spurious/transient electrical signals the host may have sent down the bus towards the devices.  What the devices saw probably didn't look anything like a legitimate reset signal, though, so it's hard to tell how they could react.

When you finally started running the host, you did it with the port enabled.  That is sort of like plugging a device into a port that is already running and enabled, but there was also probably some confusing electrical stuff going on with the bus before then.  According to the spec, devices aren't required to "react properly" until they receive a legitimate reset, so I doubt that there's anything actually wrong with your device.

[Sauro]

OK 
The important thing now is that everything works perfectly,
however, I stop and then restart the controller during transfers, I hope this thing is possible, so far I have not had any problems.
It seems pointless, that the controller is in the start state, while there is no work to be done

[Bret]

You could try suspending and resuming the devices rather than stopping and restarting the whole bus.  I suspect shutting down the bus will cause you grief someday, especially if you ever want to use "real-time" input devices (mice, keyboards, etc., or even USB hubs).

[Sauro]

OK,
Thank you very much for your reply

Cheers