- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi there,working on a ring0 singletask RTOS I have encountered an annoying problem regarding an USB UHCI controller. Testing board is an Intel Atom board D410PT with 1 EHCI and 4 UHCI companion controllers in the NM10 chipset.I can send packets to a function, but responding IN packets from the function are ignored. 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 analysed the actual USB data flow by controling the function's source code (on a SiLabs C8051F320 development kit) which works fine with Windows, Mac and Linux. Also the EHCI on the Atom board works fine!After one week of searching this error I don't have any ideas left what is happening!Is anybody out there able to give me any hint?Hopefully,Michael
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
...and again it's me! More than 100 people have already viewed this post but none has replied - looks like lots of you have problems with UHCI and not much (none?) can help with it!Well, here I'd like to give more details to my problem - hope it might help also someone else:The Problem: transfers host-to-function (full-speed) work properly, but transfers function-to-host result in the host to show a CRC/timeout error, as if the function would have send nothing.As USB-function I'm using a SiLabs C8051F320DK evaluation board, where I have programmed 2 LEDs to go ON when the GET_DEVICE_DESCRIPTOR has been received and the SET_ADDRESS control transfer has been accomplished. The function (a MIDI controller) has been tested and works fine with Windows, Linux and Mac.Here the details:When booting my Atom Board (D410PT), the BIOS enumerates the function (both LEDs go ON), thus the hardware on my board works perfectly.
(BIOS-version is MOPNV10N.86A.0178.2010.0331.0947)
The NM10 chipset of the board includes 1 EHCI with 4 UHCI companion controllers for full- and low-speed transfers.
After my kernel has started, the following is setup (in sequence) for the USB:
- - set the PCI bus master enable and memory space enable bits (if necessary)
- - get Host Control Capabilities Register address from PCI (that is EHCI at D29:F7 !)
- - check if the BIOS controls the EHCI and set control to OS. This regards bits 16 and 24 of the USB EHCI Legacy Support Extended register (offset 0x68). After this, the BIOS is not more able to access the USB-function.
- - get ehci mem space size, get Host Control Operational Register address and reset the EHCI.
- - Next I allocate memory for EHCI and UHCI queues and setup 3 framelists, 1 for EHCI use, and 2 for 2 UHCI controllers (there are 4, but only 2 will be used).
- - Register CONFIGFLAG is setup to route all ports to the EHCI first
- - The I/O addresses for the 4 UHCI controller are taken from PCI Baseaddress Register (D29:F0/F1/F2/F3) at offset 0x20
- - Every UHCI controller is now:
- stopped and globally reset
- clear all interrupt- and error-bits (register STS is ANDed with 0x1F)
- clear legacy support and detach UHCI from BIOS by writing 0x8F00 to the PCI register USB_LEGKEY at offset 0xC0
- start HCRESET (CMD |= 2) and wait till reset has finished
- USB registers are cleared (CMD, STS, INTR, FRNUM and PORTSC[0/1] are 0, SOFMOD is 0x40)
At this point I start scanning the 8 ports for attached devices (to easy testing, only 1 device is attached!). If a high-speed device is found, everything runs fine, no problem!If a full-speed device is found (EHCI port-reset leaves port disabled, ergo it must be full- or low-speed), the following is done:
- - release port ownership to a companion host controller by setting EHCI_PORTSC[port] |= (1<<13) and wait for the change to be accomplished</li>
- - store the frame list base address to the UHCI FRBASEADD register and set FRNUM to 0
- - set bit PIRQ by writing 0x2000 to the PCI register USB_LEGKEY at offset 0xC0 (enable USB-PCI interrupt, BUT: All is still done by polling, no interrupts are enabled!)
- - send a resume signal on USB for 20 ms
- - reset the connected port
- - start the UHCI controller with max packet size to 64 bytes. (The last 3 items can be exchanged in any manner, the result is allways the same!)
Now I start enumeration by invoking the get_device_descriptor transaction. The 8 bytes of the SETUP token are sent and recived by the function (LED1 goes ON) which replies with the 18 requested bytes of the descriptor. The UHCI controller runs out of CERR and returns a CRC/timeout error.Here the queue transfer definitions with the data before and after transfer:1st Transfer: Setup: After Transfer: Link pointer: 0xDEAD0001 0x1EFBFBF4 Control/Status: 0x18800000 0x18000007 Token: 0x00E0002D 0x00E0002D buffer: 0x0009FB60 0x0009FB602nd Transfer: Setup: After Transfer: Link pointer: 0x1EFBFC14 0x1EFBFC14 Control and Status: 0x18800000 0x004507FF <--- the error!!!</font> Token: 0x02240069 0x02240069 buffer: 0x0009FB70 0x0009FB70The 3rd Transfer is irrelevant - it has never been arrived up to here!
It took exactly 4 frames to arrive at the error (1 for the SETUP- and 3 for the IN-token).
HELP!!! I would be happy to hear any opinion and any ideas!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
A hack of an idea would be to remove UHCI form the equation and move to the EHCI controller, if that is possible. You need to put a USB 2.0 hub with a translator on it.
I am just putting out that the EHCI functionality may possibly be superior on this platform.
Its probably pretty late in your game for that but its an "idea"
Tony
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Michael:
Just wondering if you have tried the Intel e-Help desk for support on this issue. e-Help is an extension to the Intel Embedded Community that is staffed with technicians that support select Intel embeddded platforms, including Atom.
To access e-Help, you need to have Privileged membership status. If you already have Privileged status, you will automatcially see the e-Help discussion boards when you login to the Community. If you don't aleady have access, you can request an upgrade to your account at this link: https://edc.intel.com/My-Account.aspx?returnurl=http://embedded.communities.intel.com/post!reply.jspa?message=4349 https://edc.intel.com/My-Account.aspx.
Note that there is a process to get you set up for e-Help, including establishing a non-disclosure agreement with Intel, if your company doesn't already have one. The entire process usually takes a few days. In addition to e-Help, Privileged status also provides you with access to a wealth of technical specs and documents within the Intel Embedded Design Center. ( http://edc.intel.com/ http://edc.intel.com/)
Hope this helps
Felix
J. Felix McNulty
Community Moderator (Intel contractor)
![](/skins/images/872293744008A34B36F8ABF94A46CC66/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page