Re: Problems with usbser.sys and the bulk-in endpoint

Hi guys,

I hope you can help. I am getting desperate!

I am having the exact same problem you describe here - except my IN endpoint is not iso but set to bulk. Do you know of any other reasons why I may be getting the exact same issue? Why should the bulk-in endpoint lock up after one transmission and my bulk-out endpoint remains functioning correctly?

Also, does anyone thing using usbser.sys is a waste of time and should I be looking at using a different driver?

Thanks

> I'm having a problem using usbser.sys with an AT91SAM7S256 that I
>hope somebody can help with. I'm attempting to create a virtual COM
>port to communicate with the AT91SAM device using some legacy software
>that only communicates through PC COM ports.
>
> I'm using the IAR development system and have found an example of
>using the virtual COM ports (the file was
>at91sam7s64_basicusb_20060901_public.zip) that _almost_, but not
>quite, works.
>
> My device enumerates, usbser.sys gets loaded, the virtual COM port
>shows up, and appears to be working fine. I start hyperterm on the PC
>side, it connects to the virtual COM port, I see exchanges of line
>coding, etc, and all still seems fine. I can send characters from
>hyperterm, through out the BULK-OUT endpoint, and receive them with my
>firmware application just fine.
>
> The problem is with the BULK-IN endpoint. I can send one packet
>(from 1 to however many characters) and the entire packet makes it
>through and is displayed by hyperterm. However the BULK-IN endpoint
>then locks up on any further attempts to send data. I write the data
>to the fifo, set the TXPKTRDY bit, and it hangs in that state with
>TXPKTRDY never getting cleared and TXCOMP never getting set, so it
>appears the Host has stopped reading that endpoint. While the BULK-IN
>endpoint is stuck like this, I can still transfer characters through
>the BULK-OUT endpoint and see message exchanges through the Control
>endpoint if I change line-coding. So it's just the BULK-IN endpoint
>that's having the problem.
>
> If I use the Atmel driver (6124.sys) instead of the usbser.sys
>driver, it works fine. Both BULK-OUT and BULK-IN endpoints transfer
>data properly. The _only_ change I made when using the 6124.sys
>driver was to loopback packets on the AT91SAM device for use with an
>Atmel test program that uses the 6124.sys driver.
>
> Because of this, I figure I have to have some sort of set up issue
>with the usbser.sys driver (flow control of some sort not getting set
>up correctly???), but I'm having a hard time finding usefull
>information on the usbser.sys driver and what affects its configuration.
>
> So:
>
> Anyone have an idea what might be causing the problem?
>
> Has anyone gotten usbser.sys to work with the AT91SAM device? If so
>, could you share the .inf file and the USB configuration descriptors
>you're using? Or the entire AT91SAM code base around the USB port if
>possible.
>
> Anyone know of a source of usefull information on how to deal with
>usbser.sys?
>
> Anyone know of any substitutes to usbser.sys? It would really be
>best if I can use usbser.sys for a "driverless" solution, but in the
>end I need to get this to work.
>
> I just need very basic transport of characters from PC device.
>
> Any help is appreciated.
>
>-Cliff
>

Start a New Thread

All,

What software are you using on the ARM? I've got an implementation
of ATMEL's USB Framework with the CDC code compiled under gcc running
on a SAM7 and it works fine with usbser.sys

I DID have to spend some time tracking down a possible compiler
issue (or maybe it was a bad volatile declaration) in one of
the ISRs but now it works fine.

Have a close look at ATMEL's USB Framework. It seems complicated
but it's really quite beautiful once you figure out how it
works.

The nice part is that the low level functions are always
the same and you plug in the functionality you want such as
CDC, Mass Storage, or HID on top.

Cheers, Ralph
Start a New Thread

Hi Ralph,

I am pretty much writing my own software on IAR 4.4 platform. All I
want it to do for now is enumerate a v com port and loopback
characters from hyperterminal. Which it nearly does?

Is this the USB framework your referring to?

usb-device-cdc-serial-project-1.4-iar5-at91sam7s-ek

It seems very comlicated to set up. However I may have to give up
and attempt it.

I am really just wondering if anyone has clues as to why the IN
endpoint would freeze.

Thanks for your help.

swilson

--- In A..., Ralph Hempel wrote:
>
> All,
>
> What software are you using on the ARM? I've got an implementation
> of ATMEL's USB Framework with the CDC code compiled under gcc
running
> on a SAM7 and it works fine with usbser.sys
>
> I DID have to spend some time tracking down a possible compiler
> issue (or maybe it was a bad volatile declaration) in one of
> the ISRs but now it works fine.
>
> Have a close look at ATMEL's USB Framework. It seems complicated
> but it's really quite beautiful once you figure out how it
> works.
>
> The nice part is that the low level functions are always
> the same and you plug in the functionality you want such as
> CDC, Mass Storage, or HID on top.
>
> Cheers, Ralph
>

Start a New Thread

slouwilson78 wrote:
> Hi Ralph,
>
> I am pretty much writing my own software on IAR 4.4 platform. All I
> want it to do for now is enumerate a v com port and loopback
> characters from hyperterminal. Which it nearly does?
>
> Is this the USB framework your referring to?
>
> usb-device-cdc-serial-project-1.4-iar5-at91sam7s-ek

I started here:



> I am really just wondering if anyone has clues as to why the IN
> endpoint would freeze.

I'm pretty sure it's a bug in your software :-) I had a
heck of a time with the Frameowrk under gcc until I diagnosed
the issue with a volatile variable and then it worked
flawlessly.

Good luck.

Cheers, Ralph

Start a New Thread