topic Re: Hard evidence for usbser.sys, Now I'm all psyched up again in ColdFire/68K Microcontrollers and Processors

USB enumeration problems

Mudwog — Tue, 06 Mar 2012 11:08:29 GMT

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

Re: USB enumeration problems TYPO

Mudwog — Tue, 06 Mar 2012 12:25:31 GMT

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

Re: USB enumeration problems TYPO

mjbcswitzerland — Wed, 07 Mar 2012 07:24:03 GMT

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

Fixed response for 2.0

Mudwog — Wed, 07 Mar 2012 10:25:16 GMT

Mark,

Thankyou!

I will try both suggestions. right away.

Mudwog

Re: Fixed response for 2.0

Mudwog — Wed, 07 Mar 2012 12:04:51 GMT

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

Re: Fixed response for 2.0

mjbcswitzerland — Wed, 07 Mar 2012 19:54:44 GMT

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

Re: USB enumeration problems

cathychang — Fri, 09 Mar 2012 10:17:37 GMT

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

Re: USB enumeration problems

Mudwog — Sat, 10 Mar 2012 08:28:15 GMT

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

Re: USB enumeration problems

mjbcswitzerland — Sat, 10 Mar 2012 23:28:38 GMT

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

Re: USB enumeration problems

cathychang — Tue, 13 Mar 2012 08:24:03 GMT

hi mjbcswitzerland,

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

Re: USB enumeration problems

mjbcswitzerland — Tue, 13 Mar 2012 09:12:54 GMT

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

Re: USB enumeration problems

Mudwog — Thu, 15 Mar 2012 13:15:21 GMT

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

Re: USB enumeration problems

mjbcswitzerland — Thu, 15 Mar 2012 17:52:38 GMT

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

Re: USB enumeration problems

cathychang — Fri, 16 Mar 2012 13:53:29 GMT

hi mjbcswitzerland,

Thanks for your detailed introduce about these two tools.

I see.

Best regards,

Re: USB enumeration problems - giving up

Mudwog — Mon, 26 Mar 2012 11:49:04 GMT

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.

Re: USB enumeration problems - giving up

mjbcswitzerland — Tue, 27 Mar 2012 02:09:21 GMT

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

Re: USB enumeration problems - giving up

Mudwog — Thu, 29 Mar 2012 07:37:45 GMT

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

Re: USB enumeration problems - giving up

mjbcswitzerland — Thu, 29 Mar 2012 19:43:45 GMT

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.

Re: USB enumeration problems - giving up

Mudwog — Tue, 03 Apr 2012 00:42:06 GMT

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.

Re: USB enumeration problems - giving up

Mudwog — Tue, 03 Apr 2012 01:08:19 GMT

Attached are my Virtual COM Port Descriptors.