I managed to miss your reply until now.
Is that timeout error a bus timeout, or a protocol timeout?
A bus timeout would be where the device does not send a handshake for a packet within the required (very short) period of time (some small number of bit times). A protocol timeout is where the device does not come up with data within a long period of time set by the driver, usually 5-30 second or so.
In either case, I'd suspect the device is out to lunch.
For a bus timeout the device is so dead, the USB cell is no longer acting autonomously. Usually with a hung/crashed CPU the USB will NAK transactions so there's no bus timeout, but you do get protocol timeouts.
Also as you mention cold and bitstuff errors, I might wonder if the device has gone so far out of spec with its bit timing its responding, but the packets it sends are not received correctly by the host. Resetting the device might force it to do some recalibration which would allow the communication to work again. Looking at this with a hardware analyzer or even a scope could be very illuminating.
I once worked with a device which was sensitive to glitches on hot plug. Once in a very long time, it would see the glitch and auto calibrate its termination to one the high extreme. This was so extreme that the host would see it as an open bus at the first opportunity and disconnect it. A reset caused it to go through the calibration again and it started working. That was a fun thing to debug, which I think involved a scope and an analyzer. The analyzer to see the issue and trigger the scope to capture the problem. Once we saw the problem, which showed us as "hot SOFs", i.e. SOFs which were too high a level we could capture it with a scope.
