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

[cathychang]

hi wudwog,

the usb enumeration problem is ok?

you write a program by yourseld from zero, and dont use anyone usb stack.

i will complete the same function in my project now , i hope that your problem is solved  as soon as possible.

Unfortunately I don't understand the enum from host now

[Mudwog]

Cathychang,

I have not found any useful example code for Virtual COM port.  (It seems to me that this would be a fairly common function, but I have not found any useful information on the subject). 

I have found several example .inf's and the descriptors in Jan Axelson's book "Serial Port Complete".  But, there is no documentation that I've been able to find, and there is no example code.  I have seen some posts on other forums indicating that there are people working on USB Virtual COM Port for other processors, but no useful information.

The only comprehensible USB example code I've managed to find is the bootloader (available from Freescale's web site) where the MCF52259 behaves like a flash stick, (which was helpful, but not instructive for making a Virtual COM Port).  (I have modified that bootloader and I've been using it for my development, it is much more convenient than burning flash with the BDM device).

Currently I am stuck. 

The host simply stops communicating just before it should send a SET configuration, or SET interface command. 

If I make progress I will post any useful information I find, but right now I'm lost.

Mudwog

[mjbcswitzerland]

Hi

I'll remind a final time that there is full USB-CDC support in the uTasker project (code, documentation, simulation and professional support).

The .inf looks fine. I expect that there is still a problem during enumeration since the set configuration is the final step.

Attached is a typical enumeration sequence for USB-CDC in USB2.0 mode.

Note the following:

- there is a control transfer stall taking place when the Microsoft OS specific string descriptor 238 is received. This only occurs in 2.0 mode but you will need to ensure that it is being handled correctly. The stall just informs that it is not supported (which is the behaviour required for all unsupported requests otherwise it will fail).

- The set configuration will be sent as final stage during enumeration. If it doesn't take place there may be a problem with the information returned in the configuration descriptor. You will need to check the content being transferred. Also note that the USB controller in the M52259 can not transfer content directly from consts in Flash without using back-door accesses (in this case it would be sending blank content, or similar). If you build up the content in SRAM this workaround is not required.

- Check carefully the DATA toggling that takes place when the longer answers are sent. This needs to be controlled by the driver. If it is not correct it is only visible with an analyser which will point this out. Enumeration would otherwise fail with no clear reason or errors if it is not correct.

- After the configuration there are just 2 final endpoint 0 frames (the get line coding and the set control state). If you are sure that the set configuration is not taking place this will not yet be a potential problem.

Regards

Mark

[cathychang]

hi mjbcswitzerland,

I want to know which tool you used to get the detailed by PC  during enumeration .

[mjbcswitzerland]

Hi

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.

There is a basic version of the Beagle for $475 - http://www.totalphase.com/products/beagle_usb12/

For full class decoding and high speed the 480 costs $1'400. http://www.totalphase.com/products/beagle_usb480/

They also have a USB 3 analyser but that gets quite expensive.

The Ellisys is also very good but a bit more expensive - sometimes I just like the way it shows data (so I understand quickly what is happening and what is to be done to solve things) but this is personal preference.

For low level USB developments it is almost essential to have one (unless you are extremently lucky and all code you write just magically works... I am not so lucky... or if your employer doesn't mind paying your wages for months on end without getting a USB based project completed).

Regards

Mark

[cathychang]

hi mjbcswitzerland,

Thanks for your detailed introduce about these two tools.

I see.

Best regards,

[Mudwog]

For the time being I am giving up on the Virtual COM Port device.

I have been beating on it trying to get it to enumerate, and I am convinced that the failure to enumerate is because the Wizard has problems installing usbser.sys.  Without the usbser.sys driver the enumeration fails right after reading the full configuration descriptor.

I will try to contract a Windows expert.

[mjbcswitzerland]

Hi Mudwog

Please could you send me your binary (that is failing the enumeration) and your *.inf [or post them here].

In addition tell me which evaluation or demo board the binary is for.

I can load it and use my tools to identify exactly the reason for the problem.

Since I never experienced problems with driver installs on XP, Vista or Win 7 there is a chance that there is something going on which you haven't been able to see.

Regards

Mark

[Mudwog]

Hello mjbcswitzerland,

I'm fairly sure that my EP0 code on the MCF52259 is working.  I have re-written all of the USB portions Derek Snells Mass Storage Device Bootloader to be compatible with my system.  And I also re-wrote all of the USB portions of that bootloader in assembly language just as a learning project.

My attempt at Virtual COM Port Device is failing because i can't get the usbser.sys driver to run.  I have tried two different systems XP-SP2 and XP-SP3, same results.  It extracts usbser.sys from the .cab file and copies it into the windows drivers directory, but it will not function.

As an experiment to see if my EP0 stuff was ok, I put in the descriptors from my Mass Storage Device bootloader, and commented out the CDC descriptors.  It completely enumerated.  I did it witht he max buffer size  for EP0 set to 8, 16, 32, and 64.  It sends configuration descriptors in more than one pass with no problem, and also odd or even numbers of transmissions based on the max buffer size.  It completely enumerated, set the configuration, and only failed when the PC started trying to access it as a FLASH stick since it can't handle that.    The Mass storage driver is built in so no .inf file is needed. 

I'm fairly certain that getting usbser.sys to run is my main problem.

I am using a m52259DEMOMCU baord at the moment but I also have one mcf52259-EVB "big board" that I've also been using.  The small DEMOMCU doesn't support OTG, but that shouldn't make any difference in this case because the Virtual COM Port is a simple device.

The attached .zip contains an rtf the various error dialog boxes that windows puts up and also my .inf.

Mudwog

[mjbcswitzerland]

Hi

The typical installation does the following (the first time that the device is connected).

1) Immediately there is the enumeration to get the device specific data and start the driver install. This is however not complete since it doesn't set set the configuration yet

2) There is the period where the driver is copied - this may take 15s or so (only on first connection)

3) The enumeration now completes with a "set configuration", followed by the (CDC specific) request from the device about its setting (class IN request 0x21). The default COM port setting is then commanded by the PC host (class OUT request 0x22).

If these are not handled correctly you may get the error message that you are seeing.

4) Normally the operation will start for the first time after another 10s or so, whereby the bulk endpoint will be polled for data at a high speed (and a second bulk endpoing slowly).

Have you verified that you are correctly handling the class specific requests (these don't arrive with mass storage)? These are also on the control endpoint 0.

Regards

Mark

P.S. If you post your binary (or SREC) I can simply verify on DEMO or EVBs. This would clarify things in a few minutes.

[Mudwog]

I'm working on a different project now, hoping to hire a Windows Guy to look into this. Then I was hit by S.M.A.R.T. HDD Saturday, and I'm not yet fully recovered.  It's been a bad week.

My installations have not been typical.
Changing the Vendor ID, Product ID or serial number will cause windows to start a new installation, so I've done it several times.

Prior to copying the driver file I get a dialog box saying that the driver is no good (a screen shot is in the Word Pad file in the zip I posted).  Clicking the "continue anyway" button copies the file.  It extracts the usbser.sys from the SP2.cab and puts it into window's drivers directory.

There is never any communication after that.  It just gives the "Code 10" device cannot start.

The PC never sends the set configuration command.
The PC never sends any device specific commands.

I have device specific handlers that have never been executed (probably buggy).  I based the logic on a partial Microchip example I found on Jan Axelson's web site.

As an experiment I put the descriptors from the Mass storage device Boot loader into my Virtual COM Port device code and it did complete enumeration with that, and it did send the set configuration command.  I repeated this with the maximum size of EP0 set to 8, 16, 32, and 64 bytes.  It completed enumeration successfully every time.   It only failed after the PC started trying to access it as a Flash stick.  (I've been using the bootloader to boot my code several times a day for a long time now with no problems).

I might be able to put together a postable .s19 file in a couple of days. (I haven't yet recovered GNU and CodeWrite since the Trojan attack).  I appreciate the offer but I doubt that your debugging tools will show any new information. 

My device descriptors might be the problem, but I suspect that usbser.sys is the problem.  I installed it on an XP system with SP3, and got exactly the same results even though it has a different version of usbser.sys.

There are some partial examples, and a very sketchy description in Jan Axelson's book "Serial Port Complete", BUT... I have not seen any hard evidence that any one has ever been successful  implementing a Virtual COM Port device using usbser.sys.

[Mudwog]

Attached are my Virtual COM Port  Descriptors.

[mjbcswitzerland]

Hi

It is very time consuming and error-prone to work through files so it would certainly be simplest to run code and let the tools flag any errors.

However I did check just the first two entries and saw something that is not (absolutely) correct in the second one looked at:

CONFIGURATION_DESCRIPTOR:                 .byte 0x09                 //size of just the Configuration descriptor                 .byte 0x02                 //descriptor type - ConfigurationCONFIG_LENGTH:   .byte 0x43,0x00            //Total Length in bytes including this and all subsequent descriptors except strings. (little endian word) 67 bytes                 .byte 0x02                 //number of interfaces in this configuration.  Two interfaces                 .byte 0x01                 //Identifier for this configuratoin, only one configuration so this must be 1                 .byte 0x00                 //configuration string index (0 would mean no string)                 .byte 0x40                 //Attributes, bit pat bit7=BUS powerd, bit6=Self powered, bit5=device can wake up buss, 0=no remote wakeup  (should be 0x60 ?)                 .byte 0x64                 //maximum power consumption, I don't know how to interpret this number, 0x32means 100mA, 0x64means 200mA?

The 0x40, 0x64 at the end means a self-powered device with 200mA bus comsumption (each count is 2mA). The last should be 0 if it is self-powered.

The 0x40 is also invalid (I think) because the bit 0x80 "must" always be set - it should therefore be 0xc0, 0x00.

As I said, I didn't check more because this is quite a task and I don't know whether Windows is so strict or not about deviations from what the values should (normally) be. Maybe is explains something (or part of something)??

Regards

Mark

[Mudwog]

Today I received a demo board/kit for a peripheral chip I'm evaluating.   It used a Virtual COM Port, so I found the .inf file that it installed on my computer, and ... IT USES usbser.sys!!!

It installed with no errors or problems what so ever.  The USB converter is a PIC18Fxxxxx, and I think I found some example code for it on the Microchip site. 

This is the first hard evidence I've seen for Virtual COM Port using usbser.sys.   Now I'm all psychged to re-write my .inf again based on this Microchip version.

I will make the change to the device descriptor that you suggested.  Thanks!

My descriptors are based on a number of sources I actually dug through the 5-level deep macros to figure out what was in some of the CMX descriptors.   I filled out some of it from  the descriptors from Jan Axelson's book "Werial Port Complete", and I found the descriptors from a partial example from Micro chip.   I haven't yet figured it all out, I'm still just a beginner at USB. 

If I get this driver to install, then I'll be able to start having REAL problems.

[Mudwog]

mjbcswitzerland,

Attached is a stripped down stand alone exec for teh MCF52259 Tower kit.  It should run about the same on the DEMOMCU and the EVB though I've only been working on teh Tower lately.

It took longer than I expected, I've been busy with other things.  But if you can find anything with your sniffer it would be much appreciated.

Since my last post I have learned that the warning Windows is giving me is not a problem.  My .inf file is most likely ok.  There is a line in some .inf files that specifies a .cat file that should be in teh same directory with the .inf and the .cat file contains some sort of secure "signature" for Windows.  But drivers work fine without it.   So I'm no longer worried about that.

My USB enumeration still fails, and I have no source of information to help me figure out what the problem is.

I susect that my descriptors are wrong, or that the way I'm sending them is wrong.

Mudwog  

[mjbcswitzerland]

Hi

I ran the software on the M52259EVB and saw the following:

1) The bmAttribute in the configuration descriptor is 0x40 and is expected to be 0xc0 (bit 7 is shown as invalid but this is probably not significant)

2) The CDC interface defines two interfaces, the first (communication) defines AT commands in the bInterfaceProtocol field and the second the data interface. Both look correct although I never used the AT commands part myself - so no experience available.

3) During the enumeration the configuration descriptor looks fine since it is defined as being 67 bytes in total length (wTotalELngth) and the complete content is this size (returned as two IN frames of 64 and 3 bytes respectively).

4) The error takes place when this is requested a second time (during complete enumeration is is typical that the same blocks of information are requested a multiple number of times - I understand because different parts of the software actually communicating with it on the PC have their own independent API interfaces and ask for the details - resulting in the requests a number of times on the USB):

When it is returned the second time it reports the 67 bytes of content but only aftually sends 9 bytes of data (just the configuration descriptor part - containing the self-powered bit and 200mA consumption). The rest is missing.

This means that the PC is still waiting for the rest of the reported content and will wait either forever or reset after a timeout and tries again.

This means that the interface is never actually activated.

This looks like a basic SW error above the USB driver itself which incorrectly sets the length to be sent but does set its data pointer to the start of the correct configurator descriptor (or a function that is building these parts into the complete response).

I think that this shows that it is quite easy to be doing something not quite correctly but it is probably very difficult to debug without the correct tools (as you know, setting break points on code is not of much use since USB will timeout very quickly and reset the controller if such attempts are made, thus losing any real debugging data). If you are doing a professional USB development it would be worth investing in a tool to help (fortunately they are not that expensive nowadays [from about $400] - as they were for the first USB developers at the end of the 1990s) otherwise it is like a typical developer working without a multimeter and oscilloscope trying to work out what is happening - any one who tried this will also find that it is like working blind and can be very inefficient and sometimes impossible.

Regards

Mark

[Mudwog]

mjbcswitzerland,

Thanks!

This is a great clue.  I will follow up on it.

My Virtual COM Port project has partially preempted, other projects keep comeing up.   But I'm still working on it when I can.

Mudwog

[Mudwog]

Hello,

I've been busy these last few weeks making my boss rich(er), but last Friday night I managed to get back to this.  I put in some debugging code to save all 8 bytes of the Setup Packet  in RAM ,each time one was received.  After the enumeration failed I could then display the buffer on my terminal screen via the real UART.

After it finally made it through enumeration this is what I got:

80 06 00 01 00 00 40 00
00 05 01 00 00 00 00 00
80 06 00 01 00 00 12 00
80 06 00 02 00 00 09 00
80 06 00 02 00 00 FF 00
80 06 00 03 00 00 FF 00
80 06 02 03 09 04 FF 00
80 06 00 03 00 00 FF 00
80 06 02 03 09 04 FF 00
80 06 00 03 00 00 FF 00
80 06 02 03 09 04 FF 00
80 06 00 03 00 00 FF 00
80 06 02 03 09 04 FF 00
80 06 00 01 00 00 12 00
80 06 00 02 00 00 09 01     request for configuration descriptor with byte count of 265!
00 09 01 00 00 00 00 00
A1 21 00 00 00 00 07 00
21 22 00 00 00 00 00 00

I was only using the LS byte of the little endian requested byte count so all of the requests for 255 bytes were working, but the one for 265 bytes failed.   Converting the little endian word to bigendian instead of using just the byte setup_packet[6] got through the entire enumeration.

Now I'm off on the next bug.

Thank you much!

Mudwog

[Mudwog]

Attached are my Virtual COM Port  Descriptors.

[Mudwog]

mjbcswitzerland

I only have Internet Explorer 8.  I can't navigate the utasker forum.  But I was able to get a copy of a .zip file from the utasker web site that looked as if it contained some example code: uTaskerM522XX_V1.4-0.zip.

I can't look at anything in the .zip because it is password protected.  I didn't even know it was possible to password protect .zips or individual files...

Mudwog