CDC ACM problems on a few PCs

Discussion in 'Windows Vista Drivers' started by Magnus Nilsson, Feb 16, 2005.

  1. Hi,

    I'm having some trouble with my USB device.

    I'm posting this here, as I'm using the USBSER.SYS driver to make it
    appear as a CDC ACM modem/virtual comport, and it may be a known
    problem with the driver (well, you can always hope it's someone elses
    fault :) .

    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:
    http://magnus.freeshell.org/douglas_vcp_ok_1.txt
    I get a similar log from my laptop:
    http://magnus.freeshell.org/douglas_error_tx529.txt
    - 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'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:
    http://www.atmel.com/dyn/resources/prod_documents/doc4322.pdf
    and
    AT91RM9200-BasicUSB-ARM1_2-2_0.zip at
    http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3193

    Thanks for reading this, and if you can help me
    /Magnus
     
    Magnus Nilsson, Feb 16, 2005
    #1
    1. Advertisements

  2. (Replying to my own message:)
    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.
     
    Magnus Nilsson, Feb 17, 2005
    #2
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.