USB modem (CDC ACM) problem on some PCs (hangs)

Hi,

I'm having some trouble with my USB device.

On ~5% of the PCs it's been installed on, the serial communication hangs as soon as my device have made its first bulk IN transfer (i.e. the first bytes sent over the virtual comport). The transfer is never acknowledged, and the communication hangs.

Up to this point, enumeration and opening the comport goes well. Sending data to from host to device also works, and does not hang the device.

I put a BusHound log of an OK run at:

formatting link
I get a similar log from my laptop:
formatting link

- up until it hangs after the first IN transmission!

Both are running Windows 2000.

1) Does the problem look familiar to anyone here? 2) Could you point me to the right specs, so I can make make heads or tails of the last USB request block, NT I/O request packet and NT IRP stack location?

I'm using the USBSER.SYS driver to make it appear as a CDC ACM modem/virtual comport.

I've seen the problem mainly on laptops, but also on one stationary PC, all of them running Windows XP (but most PCs run XP now, so that may not be a factor).

My device uses the Atmel AT91RM9200 uC (with its embedded USB device controller). My code is largely based on Atmel's example:

formatting link
and AT91RM9200-BasicUSB-ARM1_2-2_0.zip at
formatting link

Thanks for reading this, and if you can help me /Magnus

Reply to
Magnus Nilsson
Loading thread data ...

What type of host controller is in the PC's that fail? Open Device Manager, select "Devices by connection" from the view menu, and find your device. See if it is connected under a "USB Universal Host Controller" or a "USB Open Host Controller" or a "USB Enhanced Host Controller". Compare with a PC where it works.

Doesnt help much. You need a USB bus analyzer to see whats really going on.

Probably wont help you. You need a USB bus analyzer to see whats really going on.

The entire USB stack was redesigned for Windows XP, to support USB 2.0. So your device may very well have a problem that only reveals itself on XP. Have you run the USB Command Verifier (usbcv) on your device? If not, download it from

formatting link
and do that first.

Leo Havmøller.

Reply to
Leo Havmøller

I found the problem: The sample code (AT91RM9200-BasicUSB-ARM1_2-2_0) defines the interrupt as /isochronos/! Not a subtle error one would think, but most USB controllers survive it and go on. The failed request to the interrupt pipe was easy to see using the SourceUSB sniffer.

Anyway, thanks for your reply Leo. I'm sure I'll use usbcv again soon.

Reply to
Magnus Nilsson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.