USB 2.0 Chirp Seems to Prevent NET2890 from working on HS USB Hub.

[USBVIDPID]

NET2890 (NET2890REV2B-LF) USB device works fine until it connected to a USB 2.0 hub with EHCI enabled. 

I am assuming that the Chirp causes the NET2890 to never interrupt the attached uP.  (confirmed no interrupt occurs)

Does anybody know of a device that could be used to filter out the chirp?

Regards, jmw

[Jan Axelson]

If you mean that you think that communications are failing because the hub port is trying to find out if the device supports high speed, that should have no effect. When a device doesn't send a chirp, communications default to low/full speed.

[USBVIDPID]

The problem is the NET Chip doesn't interrupt any more and doesn't respond to a get device descriptor after the chirp.  After the chirp, the USB device appears hung and only a hardware reset (not USB bus reset) will clear it and make it operation again.  Of course on a HS enabled bus, the reset will cause the Chirp again, so it is vicious cycle.  So if I could maybe filter the chirp, then the NET2890 might have chance to work. 

I guess the real question is, has anybody on this forum ever gotten the NET2890 to work correctly on a USB 2.0 HS bus?  If so I would like know how, so I can fix my problem without having to change the design to a USB device chip that will work when connected to a HS USB bus.  Maybe a read of the USB device receive buffer would "clear and enable" USB interrupts if it was known when the chirp had completed?

Thanks, again, jmw

[Jan Axelson]

The upstream port initiates Chirp J/Chirp K only in response to a downstream Chirp K, which the full-speed Netchip controller doesn't send.

So the problem is something else.

Endpoint zero must return ACK to the Get_Descriptor request in the Setup stage.

[USBVIDPID]

Thank you, I shall look further.  jmw