Em 06/09/2016 15:01, Hans Petter Selasky escreveu:
On 09/06/16 18:38, Otacílio wrote:
After a lot of messages this appears:
13:04:40.000436 usbus1.2
DONE-BULK-EP=0081,SPD=HIGH,NFR=1,SLEN=384,IVAL=0,ERR=0
13:04:40.000447 usbus1.2
SUBM-BULK-EP=0081,SPD=HIGH,NFR=1,SLEN=0,IVAL=0
urtwn0:
On 09/06/16 18:38, Otacílio wrote:
After a lot of messages this appears:
13:04:40.000436 usbus1.2
DONE-BULK-EP=0081,SPD=HIGH,NFR=1,SLEN=384,IVAL=0,ERR=0
13:04:40.000447 usbus1.2 SUBM-BULK-EP=0081,SPD=HIGH,NFR=1,SLEN=0,IVAL=0
urtwn0: device timeout
Hi,
A USB analyzer would tell for
Em 06/09/2016 04:44, Hans Petter Selasky escreveu:
On 09/06/16 06:47, Adrian Chadd wrote:
missing some bus
barriers for ARM or something?
FYI: Most of the USB control and data memory is coherently allocated
and don't need barriers. You can try capturing a trace using usbdump,
of the
On 09/06/16 06:47, Adrian Chadd wrote:
missing some bus
barriers for ARM or something?
FYI: Most of the USB control and data memory is coherently allocated and
don't need barriers. You can try capturing a trace using usbdump, of the
traffic on your device, and see where it hangs:
usbdump
hm, interesting! I wonder if urtwn and/or usb is missing some bus
barriers for ARM or something?
-a
On 4 September 2016 at 14:18, Otacílio wrote:
> Dears
>
> I wrote these two small programs to help debug a problem that I think I have
> found when using urtwn driver
Dears
I wrote these two small programs to help debug a problem that I think I
have found when using urtwn driver in a baglebone black. The problem is
100% reproducible.
In a server machine I run:
serverUDP 2508
In beaglebone black I run:
./clientUDP servername 2508 9216 0
All the times,