USB enumeration problems

[Mudwog]

Hello,

I am working on a USB Virtual COM port for the MCF52259 (using the big EVB board).

I hve no managed to get it to enumerate, and if been working on it for .."a while".

here are all the transactions I get,and questioms:

------------------------------------------------------------------------------------------------------------------

rx sleep, rx reset, rx reset

rx device descriptor request, tx 12 bytes, tx 0 bytes, rx 0 bytes

rx reset, rx set addr request, rx EP0 IN request then addr is set

                (Shoud I sent a zero length packet after setting the addr?)

rx device descriptor request, tx 12 bytes, tx 0 bytes, rx 0 bytes

rx configuration descriptor request, tx 9 bytes, tx 0 bytes, rx 0 bytes

rx configuration descriptor request, tx 64 bytes, tx3 bytes, rx 0 bytes

               Everything looks perfect up to this point, but I have not been

               able to find any information about the next request.

               Does any one know what could cause this request for a bogus

               descriptor type 6?

rx request descriptor type 6, tx 0bytes

               (If I don't tx 0 bytes, it stops communicating right here)

              after a 5 second delay the bogous descriptor is requested again

rx request descriptor type 6, tx 0 bytes

               after a 5 second delay it goes on

rx string 0 descriptor request, tx 4 bytes, tx 0 bytes, rx 0 bytes

rx string 2 descriptor request, tx 10 bytes ,tx 0 bytes, rx 0 bytes

rx device descriptor request, tx 12 bytes, tx 0 bytes, rx 0 bytes

rx configuration descriptor request, tx 9 bytes, tx 0 bytes, rx 0 bytes

The Host stops communicating

------------------------------------------------------------------------------------------------------------

I was thinking it shoulc get past this point without ever involving usbser.sys, but maybe not.

I'm also having problems geting it to install.  I am not a windows hack.

It gives bad messages about the dirver and then a (Code10) can't start device.

details of the istallation problems and my .inf are in the attached zip.

any help would be appreciated.

Mudwog

[mjbcswitzerland]

Hi Mudwog

Typically, people have several Web Browsers installed (they are all free - Firefox is probably the best - then Chrome and Safari are popular). IE versions tend to be slow and break things in each release but there is a "compatibility mode" that can be selected which usually makes it usable with web sites that the newer version doesn't handle as it used to do. Trying to keep some web sites compatible with new IE versions is a huge task so best to have a selection and avoid potential problems.

The latest Coldfire V2 version is in fact:

uTaskerV1.4.10 M522XX - 13.02.2012 http://www.uTasker.com/software/V1.4/uTaskerM522XX_V1.4-10.zip
================================================================================

This is complete project code for all Coldfire V2 devices (USB, TCP/IP, OS, Boot Loaders, FAT32 etc.).

The registration form is at http://www.utasker.com/Licensing/License.html ( http://www.utasker.com/Licensing/request.html)

Regards

Mark

[Mudwog]

The line:

rx configuration descriptor request, tx 64 bytes, tx3 bytes, rx 0 bytes

Should have been:

rx configuration descriptor request, tx 64 bytes, tx3 bytes, tx 0 bytes, rx 0 bytes

I didn't type in the ZLP after the 67 byte configuration descriptor is sent.

Mudwog

[mjbcswitzerland · Accepted solution]

Hi

I think that your bogus 0x06 is the USB device qualifier descriptor. This is only sent when you declare that you are in USB 2.0 mode and not when you declare USB 1.1 mode (If you simply say that you are in 1.1 mode it will probably go away). There is no disadvantage in working in 1.1 mode anyway.

You must respond to this - a fixed response is OK if you stay in 2.0 mode and don't change between enumerations:

0A 06 00 02 00 00 00 40 01 00

This is a fixed response confirming USB2.0 mode, a 64 byte rx endpoint (this has to have this value) and a single configuration (the 1 towards the end).

You need to reply to the set address with a zero data frame and set the new address only when you get an ACK from the zero frame (not before, otherwise a loss of the zero data will cause a deadlock).

You can also check out the uTasker project because it support USB-CDC, USB-MSD and USB-HID and the USB operation on the M52259 can be simulated to make work much simpler and efficient

The USB controller in the Coldfire is very solid but not always the simplest to use because the driver has to control a lot of low level details. It is handy to have a good USB analyser when doing low level developments too otherwise one can lose huge amounts of time experimenting without really knowing the underlying details.

I use the Ellisys USB explorer and also the Total Phase USB Beagle 480 - each has its own main strengths and the Beagle is a well priced one with full class decoding as standard.

The USB user's guide is here: http://www.utasker.com/docs/uTasker/USB_User_Guide.PDF which discusses USB-CDC. For general USB tecnical discussions the forum there http://www.utasker.com/forum/ can also be used.

Regards

Mark

[Mudwog]

Mark,

Thankyou!

I will try both suggestions. right away.

Mudwog

[Mudwog]

Mark,

I tried both suggestions:

Changing the device descriptor from 2.0 to 1.1 made the bogous request for descriptor 6 go away.

Adding the fixed response device qualifier descriptor for 2.0 seemed to satisfy windows and it went on

after that without the 5 second delay and retry.

In this case I got the very annoying bubble message saying "this device can run faster blah, blah, blah"

(which I'm suspecting could indicate that there is something else wrong wtih my descriptors, since it was plugged

into a relatively modern High-speed capable USB port on my computer, which should handle Full-speed

with no problem).

If there's nothing else wrong with my descriptors, then I would say that avoiding that very annoying message would

be a big advantage to changing to 1.1.

Of course my stuff is still failing, it looks like I still have a long way to go, but at least the bogous descriptor 6

mystery is solved.

Thanks,

Mudwog

　

　

　

　

[mjbcswitzerland]

Hi

Yes, emumeration is just the beginning of the USB journey - although  having developed USB drivers for a number of different USB controllers it is always a bit like going through hell since each one does it a completely different way and the details are never explained in the user manuals (there may be huge amounts of text there but the relevant details are only identified by trial and error and reading between the lines, plus "burning mignight oil") .

Fortunately the Coldfire and Kinetis are almost compatible so this only needs to be suffered once..;-)

My original Coldfire USB development took about 1 year to get operating fully reliably (as far as that is possible to known) and since then has verified in a number of industrial projects, including running intensive MODBUS over USB, which was very easy to set up but I didn't see it done over USB before - although that development time inlcuded also generic USB framework and USB classes. I budget 2..3 months for new drivers (eg. I just completed an STM32F4xx version) from start to validation even though they share the generic USB class stuff because they are such pigs to get absolutely right to be trusted for productive use (and sometimes there is some undocumented errata to workaround in new devices where you are pretty much "on your own").

Regards

Mark