FS device crashes unless recevies Clear Endpoint Halt

[mdlayt]

So I tracked my Mac problem (from the thread about the Mac kernel trace) down to this.

Apparently Windows XP (as well as an older version of Linux and perhaps other OS's) has a work around just for my device.  After Set Configuration it does Clear Endpoint Halt.  After this, my device works perfectly, including Windows Qual.

But, surprise!  This doesn't happen on a new Linux and Max OS X 10.6.5.  In this case, my device just goes away.  According to my Beagle trace, the INs are "ORPHANED."  After a thousand or so retries, the OS gives up and retries a reset, which always turns out the same.

I dug into the USB library code and added code to poke the Endpoint Mode to NAK, which did cause NAKs to occur, instead of the "ORPHANED" transfers.  (Didn't make it work, yet, though.)

It is a HID mouse, full speed, mostly "normal" device and configs--single IN endpoint, somewhat long report desciptor and reports 13 bytes.

Does this ring any bells with anyone?

Someone must know something about this because the Clear Endpoint Halt is there.  There is no reason I know of for it to be there other than as a workaround for a broken device.  We even spellunked around in the Linux source and found it there--but only in an old version.

I could post the Beagle traces, desc's, code, or whatever, although I think I've got the gist of it here.

Obviously I have a support call in with my chip vendor, but last time it took two weeks for me to figure out and explain the problem to the tech support person well enough for him to say, yeh, that is a problem in the sample design and no, they aren't going to release a fix.

[Jan Axelson]

What is the device controller?

Jan

[mdlayt]

CY7C64343
Cypress enCoRe V

[mdlayt]

Well, I'm thrilled to admit that this was, in fact, a bug of my own creation.  I had moved the Endpoint function table to RAM, but it wasn't working.  So the endpoint was only getting configured by luck and or by the extra call in Windows and "old" Linux.  The miracle was that it worked at all.  That is a topic that deserves its own thread, I think.

Interestingly, I think this is also the bug I was dealing with when I was having problems with "endpoint addresses."  I'm going to look up that thread also.  That behavior was that I could only configure EP1 and EP2 as IN and OUT in a particular order.  The other order made them not work.  Now it makes sense based on everything I have reverse-engineered.

Question:  If it wasn't really anything called engineering in the first place, is it still reverse-engineering when you figure out what it does?

[mdlayt]

I can't find the thread on "endpoint addresses."  I think that was on the USB.org forum.

But in any case, I'm pretty sure it was the same bug.

[Jan Axelson]

Question:  If it wasn't really anything called engineering in the first place, is it still reverse-engineering when you figure out what it does?

Yes of course, reverse-engineering something that wasn't really anything called engineering in the first place is the hardest of all! Thanks for reporting what you found.

Jan