Re: Packets that are exactly a multiple of the EP size fail

Thanks,

That's exactly what the problem was.  Unfortunately, I can't fix the firmware, so I will have to deal with the slower speed.

Chris

-----Original Message-----
From: Travis [mailto:[email protected]] 
Sent: October 30, 2014 6:01 PM
To: [email protected]
Subject: Re: [Libusb-win32-devel] Packets that are exactly a multiple of the EP size fail

Greetings,

After your device sends 64 bytes (or an interval of wMaxPacketSize), it must either send more data or send a ZLP packet. This is part of the USB specifications. Transfers that end on an interval of wMaxPacketSize or considered incomplete.

A work-a-round is to use only a 64 byte buffer in your code but performance will be poor. This is the only other condition that end a bulk transfer. IE: BytesReceived==MaxTransferSize


Regards,
Travis

On 10/30/2014 1:59 PM, Chris Chaffey wrote:
>
> Hi All,
>
> I'm using LibUsb-Win32 version 1.2.6 to communicate with a device that 
> I am trying to reverse engineer. When the device sends data to me that 
> is not equal to a multiple of the endpoints wMaxPacketSize, I never 
> receive that packet. I have used a program called freeusbanalyzer that 
> has given me the following output (with some annotations on my part):
>
> <-------------- In the middle of streaming download from device
>
> 00000348 30.10.2014 16:24:47.289 +0.094 UP 0x00000000 
> URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER <-- Streaming data
>
> 00000350 30.10.2014 16:24:47.392 +0.100 DOWN 0x00000000 
> URB_FUNCTION_ABORT_PIPE
>
> 00000351 30.10.2014 16:24:47.392 +0.0 UP 0xc0010000 
> URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER <-- Zero byte
>
> 00000352 30.10.2014 16:24:47.392 +0.0 UP 0x00000000 
> URB_FUNCTION_ABORT_PIPE
>
> 00000354 30.10.2014 16:24:47.488 +0.094 UP 0x00000000 
> URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER <-- Streaming data
>
> 00000356 30.10.2014 16:24:47.591 +0.100 DOWN 0x00000000 
> URB_FUNCTION_ABORT_PIPE
>
> 00000357 30.10.2014 16:24:47.591 +0.0 UP 0xc0010000 
> URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER <-- Zero byte
>
> 00000358 30.10.2014 16:24:47.591 +0.0 UP 0x00000000 
> URB_FUNCTION_ABORT_PIPE
>
> 00000360 30.10.2014 16:24:47.688 +0.095 UP 0x00000000 
> URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER <-- Streaming data
>
> 00000362 30.10.2014 16:24:47.791 +0.100 DOWN 0x00000000 
> URB_FUNCTION_ABORT_PIPE
>
> 00000363 30.10.2014 16:24:47.791 +0.0 UP 0xc0010000 
> URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER <-- Zero byte
>
> 00000364 30.10.2014 16:24:47.791 +0.0 UP 0x00000000 
> URB_FUNCTION_ABORT_PIPE
>
> 00000366 30.10.2014 16:24:47.894 +0.100 DOWN 0x00000000 
> URB_FUNCTION_ABORT_PIPE
>
> 00000367 30.10.2014 16:24:47.894 +0.0 UP 0xc0010000 
> URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER <-- Zero byte
>
> 00000368 30.10.2014 16:24:47.894 +0.0 UP 0x00000000 
> URB_FUNCTION_ABORT_PIPE
>
> 00000370 30.10.2014 16:24:47.899 +0.002 DOWN 0x00000000 
> URB_FUNCTION_CONTROL_TRANSFER
>
> 00000371 30.10.2014 16:24:47.899 +0.0 UP 0x00000000 
> URB_FUNCTION_CONTROL_TRANSFER
>
> 00000372 30.10.2014 16:24:47.900 +0.0 DOWN 0x00000000 
> URB_FUNCTION_CONTROL_TRANSFER
>
> 00000373 30.10.2014 16:24:47.900 +0.0 UP 0x00000000 
> URB_FUNCTION_CONTROL_TRANSFER
>
> 00000374 30.10.2014 16:24:47.901 +0.0 DOWN 0x00000000 
> URB_FUNCTION_CONTROL_TRANSFER
>
> 00000375 30.10.2014 16:24:47.901 +0.0 UP 0x00000000 
> URB_FUNCTION_CONTROL_TRANSFER
>
> 00000376 30.10.2014 16:24:47.902 +0.0 DOWN 0x00000000 
> URB_FUNCTION_CONTROL_TRANSFER
>
> 00000377 30.10.2014 16:24:47.902 +0.0 UP 0x00000000 
> URB_FUNCTION_CONTROL_TRANSFER
>
> 00000378 30.10.2014 16:24:47.997 +0.094 DOWN 0x00000000 
> URB_FUNCTION_ABORT_PIPE
>
> 00000379 30.10.2014 16:24:47.997 +0.0 UP 0xc0010000 
> URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER <-- Streaming data; never 
> receive this "chunk"
>
> 00000380 30.10.2014 16:24:47.997 +0.0 UP 0x00000000 
> URB_FUNCTION_ABORT_PIPE
>
> 00000382 30.10.2014 16:24:48.099 +0.100 DOWN 0x00000000 
> URB_FUNCTION_ABORT_PIPE
>
> 00000383 30.10.2014 16:24:48.099 +0.0 UP 0xc0010000 
> URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER <-- Zero byte
>
> 00000384 30.10.2014 16:24:48.099 +0.0 UP 0x00000000 
> URB_FUNCTION_ABORT_PIPE
>
> 00000386 30.10.2014 16:24:48.193 +0.091 UP 0x00000000 
> URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER <-- Next block of streaming 
> data. Fails because previous chunk was not received.
>
> 00000388 30.10.2014 16:24:48.197 +0.002 DOWN 0x00000000 
> URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER <-- Stop stream message
>
> 00000390 30.10.2014 16:24:48.292 +0.095 UP 0x00000000 
> URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER <-- Stop stream ACK
>
> 00000392 30.10.2014 16:24:48.300 +0.005 DOWN 0x00000000 
> URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER <-- Restart at failed chunk
>
> The problem pops up at 30.10.2014 16:24:47.997. This chunk is exactly
> 64 bytes in length. It doesn't matter how many times I request that 
> chunk it will always fail. This happens in other parts of the stream 
> as well, and it only seems to be when the chunk is a multiple of 64 
> bytes in length. The only other difference I see between that chunk 
> and all the other chunks that do go through is that it always has a 
> status of USBD_STATUS_CANCELED (0xc0010000).
>
> My code is fairly straight-forward and it is executed in a thread:
>
> intsize=maxInSize*4;
>
> uint8_tbuf[size];
>
> intlen=0;
>
> intr=libusb_bulk_transfer(handle,epIn,buf,size,&len,MAX_RECV_TIMEOUT);
>
> if((r!=LIBUSB_ERROR_TIMEOUT)&&(r!=LIBUSB_SUCCESS))
>
> {
>
> //ThismethodwilltimeouteveryMAX_RECV_TIMEOUTmillisecondswhennodataisavailable.Noneedtologthiscondition.
>
> LogLibUsbReturn(r,"libusb_bulk_transfer");
>
> }
>
> if((r==LIBUSB_SUCCESS)&&(len>0))
>
> {
>
> std::lock_guard<std::recursive_mutex>lock(readMutex);
>
> inData.append((char*)buf, len);
>
> }
>
> Thanks for your time,
>
> Chris
>
>
>
> ----------------------------------------------------------------------
> --------
>
>
> _______________________________________________
> Libusb-win32-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel


------------------------------------------------------------------------------
_______________________________________________
Libusb-win32-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5315 / Virus Database: 4189/8480 - Release Date: 10/30/14

------------------------------------------------------------------------------