Need help for USB UHCI programming

[muragavino]

Hi there,

working on a ring0 singletask RTOS I have encountered an annoying problem regarding an USB UHCI controller.
My testing hardware is an Intel Atom board D410PT which has a NM10 chipset with 1 EHCI and 4 UHCI companion controllers.

Using any of the 4 UHCIs, I can send SETUP and OUT packets to a function, but responding IN packets from the function are ignored.
An example: The SETUP packet of the get_device_descriptor() arrives in the function, which then replies with the usual 18 bytes, but UHCI hardware sets the IN transfer descriptor as if nothing would have been sent back (C_ERR runs out and the CRC/Timeout bit is set in the status-field).

I'm analysing the actual USB data flow on the function side by controling the function's source code (using a SiLabs C8051F320 USB development kit). The function works fine with Windows, Mac and Linux.
Also there is no problem with the EHCI controller, all EHCI related USB on the Atom board works perfectly!

In attachment I've put a file ("Asking for UHCI help 2.txt") with a detailed description of my reset and setup procedures for the UHCIs.

After one week of searching this error I don't have any ideas left what else to try!
Is anybody out there able to give me any hint?

Hopefully,
Michael


[attachment deleted by admin]

[Jan Axelson]

I'm not a UHCI expert, but are the data toggles correct? Does the host ACK the received data?

Jan

[muragavino]

I'm not a UHCI expert, but are the data toggles correct? Does the host ACK the received data?

Jan

I'm (still) only trying to get through GET_DEVICE_DESCRIPTOR. The SETUP packet (toogle bit=0) is ACKed.
The IN packet (toggle=1) then gives the CRC/timeout error evenso my function has replied correctly!
The following OUT packet is not sent, due to the error interrupt caused by the IN packet.

[Bret]

Have you verified that both TD's (the SETUP and the IN) are formatted completely correctly, that the 8-byte setup packet data is absolutely correct, and that you aren't requesting more data than the end point can send in a single packet?

[muragavino]

Yes, I have verified all very carefully and today I have also experimented with erros:
By putting intentionally the wrong toggle bit in the IN transfer-descriptor (toggel=0 instead of =1) and with the interrupts activated, I don't get an error, but simply nothing! That means an interrupt has captured the error. It must be an interrupt, not an event or break, since with disabled interrupts I can poll for the error normally.
I then re-vectored all protected mode ISRs to see where the interrupt comes from, just to see that still a real-mode ISR from the BIOS must be active! Since I have released EHCI from BIOS (in the LEG_EXT_CAP register) as prescribed, there must be still some other BIOS related register, I suppose. I've searched my chipset datasheet for "UHCI", but didn't find anything relevant.

Any ideas how to release the UHCIs definitely
Must there occure a reset and new setup of the PCI