USB OHCI specification.

[BenLunt]

But... I just happen to be going through the EHCI specs as we speak, and I specifically remember reading earlier today that most EHCI controllers will default to pass through control to any USB 1.x controllers. It even justified this stating that it was done for backward compatibility for OSes that didn't have USB 2.0 support, but that did have USB 1.x support.

I definately got the impression that you had to specifically enable the global "default owner" register bit if you wanted the EHCI controller to own all ports by default.

You are absolutely correct. However, this implies that he/she found the EHCI controller and made sure this bit was set (or clear). The BIOS may have it enabled by default. Usually, if the BIOS knows about EHCI, it will enable the EHCI. Check the BIOS settings.

I am with you. 'mindentropy' either needs to familiarize him/herself with the EHCI to be sure that it passes all control to the OHCI, or make sure that there is no EHCI on board and that the OHCI is the only controller present.

Ben

[BenLunt]

My ARM development board has only the OHCI (Rev 1.0 compatible) and USB (Rev 1.1 compatible). It has support for both low speed and high speed devices. The USB stick (Ver 2.0 compatible) shows as high speed device for me. I have attached the block diagram for reference. I think I can eliminate compatibility problems here.

The diagram says low- and full-speed devices. OHCI cannot handle high-speed devices *as* high-speed devices. However, a high-speed device should enumerate as a full-speed device. Was this a typo or have you confused full- and high-speed devices. They are considerably different devices.

This means that you most likely do not have a EHCI controller, correct? Only the OHCI?

If this is correct, I will post a reply to the other message.

[BenLunt]

Just a few points that I noticed:
1. Your buffer length field should be 7, not 9. (It's actual buffer length - 1)

Is it present in the spec? I did not find this in the MaximumPacketSize definition.

As a full-speed device, you might be able to set the max packet size to 63, a 64-byte packet. However, you must check the device's Device Descriptor first. But, this is the chicken before the egg. How can you get the Device Descriptor without first knowing the max packet size? Hence, you always request an 8-byte packet as the first packet. The Max Packet Size field in the Descriptor is within this eight bytes.

So, as 'SpyderTL' suggested, use a length value of 7 (8 bytes).

2. I'm using TDCTRL of 0xE0E00000 for TD0, and 0xE0F00000 for TD1. I'm too lazy to look up the bits right now, but give it a shot.

You have ignored the T (DataToggle bits). The problem is in the spec it says:
For control endpoints, the convention is that the Setup packet will always use a data PID of DATA0, the first data packet will use a data PID of DATA1, and the Status packet will use a data PID of DATA1. Since this sequence does not rely on any previous data toggle history, the Setup, data, and status packets should be queued with the MSb of the dataToggle field = 1 and the LSb of each TD set appropriately (Setup = 0; Status = 1; and first data, if any, = 1.) Although the Host Controller updates the toggleCarry bit in the ED whenever a General TD is retired, the data toggle is determined solely by
the General TD.

I have set the SETUP TD DataToggle to 10b and Status TD DataToggle to 11b.

Correct. The SETUP TD has a toggle bit of 0 (DATA0). Then the first Data TD, if any, starts with a toggle bit of 1 (DATA1), toggling (hence the name) to DATA0, then DATA1, etc., until all Data TD's are processed. Then the (required) Status TD has a toggle bit of 1 (DATA1) no matter what the last Data TD's toggle bit was.

Therefore, a request of the first eight bytes of the Device Descriptor would be:

DATA0, DATA1, DATA1

A Set Address request would be

DATA0, DATA1

The device will watch for these bits and if it finds one out of order, it will ignore the TD.

3. ED.TailP should probably be 0x00000000. See Ben's response above to understand why.

I get the same no response. I have kept the ED.TailP == 0 and NextTD == 0 as per Ben and the spec.

4. Make sure you have reset the port before sending any commands to the device. Set bit 4 on the port status/control register and wait for it to flip back to zero before sending any data.

I have done it. Hope it is correct.

5. Just for sanity, make sure any other controllers are disabled, specifically any EHCI controllers.

No EHCI controllers in my SoC. Everything else is disabled.

Try fixing your Data Toggle bit process. I am guessing this is the problem.

Ben

[mindentropy]

This means that you most likely do not have a EHCI controller, correct? Only the OHCI?
If this is correct, I will post a reply to the other message.

Yes I only have the OHCI.

Try fixing your Data Toggle bit process. I am guessing this is the problem.

I am not sure how I can fix this. Aren't my packets right? I have set the first TD to 10b and the second TD to 11b. After correction following are my values:

Code: Select all

ED:
Endpt ctrl: 0x00080000 --> MaximumPacketSize == 8 bytes.
TailP: 0x00000000 --> Corrected as per your comment.
HeadP: 0x30007820
NextED: 0x00000000

TD0:
TD addr:0x30007820
TDCTRL : 0xE2E00000 --> Setting the DataToggle to 10b
CBP : 0x30007618
NXT_TD : 0x30007830
buffer_end: 0x3000761F --> Corrected as per your comment.

TD0 buffer dump: 0x00 0x05 0x01 0x00 0x00 0x00 0x00 0x00

TD1:
TD addr:0x30007830
TDCTRL : 0xE3F00000 --> Setting the DataToggle to 11b
CBP : 0x00000000
NXT_TD : 0x00000000
buffer_end: 0x00000000

Result:
USB State : Operational
HccaDoneHead: 0x30007821

HCCaDone Head TD Dump:

TD addr:0x30007820
TDCTRL : 0x5EE00000
CBP : 0x30007618
NXT_TD : 0x00000000
buffer_end: 0x3000761F

ERROR Status-> Device not responding

[zaval]

Ben, I really need your book on USB, but I can't get - is it sold in the .pdf form? ("kindle" is not clear what the format is for me).

Kindle is in fact the name of a specific format, namely, the format developed for the original Amazon Kindle e-reader about ten years ago, and subsequently used in Amazon's cloud and webapp distribution methods as well. It is a proprietary format, and one designed with DRM from the outset, which is great for authors but also tends to leave your books at Amazon's ransom (as the webapp and e-reader only keep a handful of books in local cache at a given time, with anything you haven't read recently only stored on their cloud servers).

While Amazon have, for the most part, operated their Kindle services in good faith, there have been some problems (fewer than, say, iTunes, but they have occurred). In general, though, it is a good service, but if you have an ideological problem with DRM (as many do), it can be seen with distaste.

Personally, I have no issue with DRM in principle; assignment of authorship credit and support for micro-payments (ones which actually lived up to the name, that is, with lower boundaries in the range of a ten-thousandth of a cent) were two of the primary goals of Xanadu, and for good reason (they still are, though I don't know how far the released version that finally came out in 2014 goes in the planned support - yeah, it took them 53 years to get half the job done, I know, I know, but I still think the ideas are sounder than those at the heart of most current systems).

However, ideology aside, DRM got a bad name as much from the many terribly designed and heavy-handed most approaches to 'copy protection' over the years - and the fact that it is, in a real sense, counter to the general behavior of computers - as it did from worries about loss of freedom. and while I have some real problems with it in practice, the fact remains that the alternative is to abandon copyright and for-profit authorship entirely.

Kindle is, fortunately, a relatively light touch when it comes to its requirements and restrictions, and I have several books which I have purchased in this way. There is some trepidation over the fact that I don't really have control over them, but that holds true with anything 'on the cloud' (e.g., distributed and mirrored over remote servers through automatic means - I would complain about the term 'cloud' being cybercrud and doublespeak, but I've already beaten that horse to death long since).

No, I have nothing ideologically problematic with DRM. The problem is easier: I don't have that e-reader. And thus never used their (possible) online services, oh, sorry, - "cloud" services. For me this word in this sense (or rather without any) is a trigger, to ignore everything related (not DRM or "proprietary").

[BenLunt]

Code: Select all

TD1:
TD addr:0x30007830
TDCTRL : 0xE3F00000 --> Setting the DataToggle to 11b
CBP : 0x00000000
NXT_TD : 0x00000000
buffer_end: 0x00000000

At the moment, the only thing I can see is that you set the Delay field in the Status TD (TD1) to 111b. This should be 000b in the Status TD.
A value of 111b in the Setup TD (TD0), but a value of 000b in the Status TD.

Try that.

Sorry I haven't been much more help. I am sure it is frustrating.

Ben

[dozniak]

Ben

Ben, check PM pls.

[SpyderTL]

I would try setting up the ED as a low speed device to see if that makes any difference.

Ben also mentioned that some devices expect a GET_DESCRIPTOR command before the SET_ADDRESS command. You might want to give this a shot.

If that doesn't work, it's time to go back and check all of your assumptions. I assume that your physical board actually works. Have you tested this device on this board using another OS? Have you tried any other USB devices? Try swapping to port 2.

Check your port reset logic again. Maybe try waiting for an additional 100ms after the port reset is complete before sending any data.

If it makes you feel any better, I'm having a similar problem with my EHCI code where the controller simply refuses to process my descriptors. So I'm probably going to have to start a whole new thread for that.

[BenLunt]

Ben

Ben, check PM pls.

dozniak,

I tried to respond, but your mail box doesn't accept a response. You have it set so no one can send you messages.

However, to answer your question:

"I bought the kindle version of your book, is the companion ISO available for it too, and how may I receive it?"

Simply send me an email at fys [at] fysnet [dot] net with the proof of purchase and I will reply with the ISO attached.

Why a proof of purchase, Ben? Well, Ben, thanks for asking. I am simply trying to keep the honest people honest. I don't question if you have the book, but I am simply trying to keep people from emailing me "hey, I have the book, send me the ISO" when they really don't. It may be a lost cause, but that's what I do.

Thanks,
Ben

[dozniak]

I tried to respond, but your mail box doesn't accept a response. You have it set so no one can send you messages.

Simply send me an email at fys [at] fysnet [dot] net with the proof of purchase and I will reply with the ISO attached.

Oops, didnt know that. Will do!

[Schol-R-LEA]

No, I have nothing ideologically problematic with DRM. The problem is easier: I don't have that e-reader. And thus never used their (possible) online services, oh, sorry, - "cloud" services. For me this word in this sense (or rather without any) is a trigger, to ignore everything related (not DRM or "proprietary").

Amazon does provide a web-based client for the Kindle format that should work with most JavaScript-enabled browsers regardless of OS, as well as desktop and mobile apps for Windows, MacOS, Android, and iOS (but not Linux, of course - well, unless you count the Android app, or, oh yes, the one used by the Kindle e-readers themselves).

However, given that you seem to dislike that term - which Amazon uses to excess in that client and elsewhere - even more than I do, I don't know how inclined you would be to use it.

[zaval]

No, I have nothing ideologically problematic with DRM. The problem is easier: I don't have that e-reader. And thus never used their (possible) online services, oh, sorry, - "cloud" services. For me this word in this sense (or rather without any) is a trigger, to ignore everything related (not DRM or "proprietary").

Amazon does provide a web-based client for the Kindle format that should work with most JavaScript-enabled browsers regardless of OS, as well as desktop and mobile apps for Windows, MacOS, Android, and iOS (but not Linux, of course - well, unless you count the Android app, or, oh yes, the one used by the Kindle e-readers themselves).

However, given that you seem to dislike that term - which Amazon uses to excess in that client and elsewhere - even more than I do, I don't know how inclined you would be to use it.

Thank you. If their "cloud" desktop application is not very cloudy such that it is able to run on the Windows XP smoothly without hanging the machine or frying the CPU, it can be worth of using it even for the Ben's book alone.

(but not Linux, of course - well, unless you count the Android app, or, oh yes, the one used by the Kindle e-readers themselves).

I guess they have a bearded explanation for that. No doubt they love open-source though.)

[mindentropy]

I would try setting up the ED as a low speed device to see if that makes any difference.

Ben also mentioned that some devices expect a GET_DESCRIPTOR command before the SET_ADDRESS command. You might want to give this a shot.

If that doesn't work, it's time to go back and check all of your assumptions. I assume that your physical board actually works. Have you tested this device on this board using another OS? Have you tried any other USB devices? Try swapping to port 2.

Check your port reset logic again. Maybe try waiting for an additional 100ms after the port reset is complete before sending any data.

If it makes you feel any better, I'm having a similar problem with my EHCI code where the controller simply refuses to process my descriptors. So I'm probably going to have to start a whole new thread for that.

Yesterday before you had suggested it I tried connecting a USB keyboard and mouse. Both set the "Low Speed Device Attached" (LSDA) bit. From this I tried running my code with the ED and TD corrections. The results are kind of surprising.

For the keyboard I get "NoErr". For my mouse I get the device not responding. I am happy to see at least something is working but I am not able to understand how this worked.

I am yet to try sending the GET_DESCRIPTOR and then GET_ADDRESS. I will do some code refactoring to make it more parametrised for experimenting.

I am also referring to a book "Universal Serial Bus System Architecture" by Don Anderson after a brief gap.

[mindentropy]

Ben,

The funny part is when I connect the USB 1.1 devices i.e. the keyboard I don't have any issue. Does a USB2.0 device need something extra?

[BenLunt]

Ben,

The funny part is when I connect the USB 1.1 devices i.e. the keyboard I don't have any issue. Does a USB2.0 device need something extra?

It is not suppose to. A USB 2.0 device, (for that matter, a USB 3.1 device with a standard Type A connector) should connect and show as a full-speed device. (see note 0 below). However, please note that a device, especially some USB 3.1 devices, only need to enumerate to the point that the HOST can determine that it needs to be plugged into a more modern controller and connection. I don't think this is the case in your situation.

What type of board do you have? Did you make the board? The hardware determines if you have a low-speed or full-speed device attached by the pull-up resister either on the D+ side or the D- side. (See note 1 below) Could your board possibly not recognize this situation?

Throughout my research and tests, I also found a few situations where a high-speed device, plugged into a UHCI controller, would not enumerate as it should. I came to the conclusion that the device was manufactured with the assumption that it would only be plugged in to a high-speed controller and had the missing hardware and/or firmware to allow a connection to a low-/full-speed controller. It can happen. Cheaper to manufacture.

Ben

[Note 0:]
It is a common misconception that a USB 2.0 device is high-speed only. The USB version number has little to do with the speed of the device. A USB 3.0 device can still only be a low- or full-speed device, while a USB 1.0 device works just fine on a super-speed controller. The USB (increasing) version number indicates what the device should comply with if it is for example, a high-speed device. The USB version number is the version of the standard USB specification it complies with, which is (mostly) backward compatible. The USB specification, USB 2.0 for example, and discussed in this thread (or another similar thread) does have a non-backward compatible issue. USB 2.0 states that a device should move to the enabled state once successfully reset. USB 1.x did not state this and OHCI, which was before USB 2.0, gave a way to enable the device. Anyway, please don't confuse the USB specification number with the speed of the device.

[Note 1:]
To indicate what speed a device is, a device should put a 1k5 Ohm resistor from 3v3 to the D- side to denote a low-speed device, or to the D+ side to denote a full-speed device.