I forgot to mention that only one of the BAPs run Bluetooth over USB,
the other one runs over a UART interface. (Both modules are CSR
however.)
The original setup looked like this:
(USB) (UART)
PC -- eth -- BAP1 -- bluetooth -- BAP2
where BAP1 acts as a bridge. So, pinging BAP2 results in bulk OUT
traffic for ping requests, and ping replies produce bulk IN traffic.
I tried switching places between them, like this:
(UART) (USB)
PC -- eth -- BAP2 -- bluetooth -- BAP1
with BAP2 now acting as the bridge. Of course, ping requests now result
in bulk IN traffic, and ping replies result in bulk OUT traffic.
It works slightly better this way; I can ping with larger sizes, but
it's still very shaky. Now it's the bulk OUT endpoint that fails, in at
least the following two ways:
1. Three hand-shake timeouts, i.e. after the DATA stage I get neither
ACK, NACK, nor STALL. (After three successive timeouts I get a HC
interrupt which disables the endpoint descriptor.) The funny thing is
that a couple more bulk OUT transactions take place after this, and then
it starts to respond with a STALL.
2. One hand-shake timeout, after which the endpoint STALLs every OUT
transaction.
At least the stalls indicate a valid error condition, as opposed to the
continuous NAK'ing of bulk IN transfers I got in the previous setup.
Does anyone know of any CSR success stories regarding USB? Couldn't
find it in the working devices list pointed to from linux-usb.org, OTOH
I found at least one guy on this list who had a similar problem (also
CSR hardware):
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=100325073108646&w=2
Thanks,
Orjan
--
Orjan Friberg
Axis Communications AB
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
