Hi Thanks for your reply. I was partly wrong, indeed, testing a bit too "roughly". We were able to modify our board's firmware to allow various tests. 16k transfers are accepted in both directions. We could read and write without error. 32k fails in both directions: Sending a 32k buffer to the board results in a too small packet sent to the board between 16 and 32k. Reading 32k from the board results in a kIOReturnOverrun error. The transfer fails with kIOReturnOverrun (0xe00002e8) also usually between 16 and 32k. I have had sometimes an error shortly above 4k, thus my first assumption. The board's firmware is not faulty, the error always comes from the OS (too short packet out, kIOReturnOverrun in). Would like to file a bug for this, but the list's experience would certainly help...
Thanks Éric Gorouben > Le 25 mars 2015 à 05:26, Stuart Smith <[email protected]> a écrit : > > why do you say that transfers >4k don't work? Is your assertion based on > the value of request.wLength on return from the DeviceRequest call? > > On the bus you show a failure after 321 packets of 64B each - that's > 20,544 bytes, a lot more than 4k. > > I'm not aware of any such limitation, although most of the devices I've > worked with use a pipe other than 0 for large transfers so perhaps I've > just never run into it. > > Stuart > > On 3/24/15, 12:00 PM, "[email protected]" > <[email protected]> wrote: > >> Date: Tue, 24 Mar 2015 17:43:08 +0100 >> From: Eric Gorouben <[email protected]> >> To: "[email protected] at Apple" <[email protected]> >> Subject: Re: Failing USB vendor request >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset="utf-8" >> >> Hi Again >> >> It looks like there is a problem transferring more than 4k over the >> default control pipe using DeviceRequest (in both directions). If I try >> to read 32k, the OS stops reading after 4k. >> Is there a way to transfer bigger data amounts in one request? >> >> Thanks >> Eric Gorouben >>> Le 23 mars 2015 à 15:50, Eric Gorouben <[email protected]> a écrit : >>> Hi There >>> I'm trying to issue a 32k transfer over endpoint 0. >>> My request is >>> UInt8 *pData; // Allocated, filled with correct data... >>> IOUSBDeviceInterface **deviceIntf; // Successfully passed all >>> rituals to become a good IOUSBDeviceInterface... >>> IOUSBDevRequest request; >>> kern_return_t kernResult; >>> request.bmRequestType = ((kUSBOut << kUSBRqDirnShift)| (kUSBVendor >>> << kUSBRqTypeShift) | kUSBDevice); >>> request.bRequest = 0x55; >>> request.wValue = 0; >>> request.wIndex = 0; >>> request.wLength = 0x8000; >>> request.pData = pData; >>> kernResult=(*deviceIntf)->DeviceRequest(deviceIntf,&request); >>> The transfer starts on the bus, split in 64B packets as expected... >>> 8 B SETUP txn 40 55 00 00 00 00 00 80 >>> 64 B OUT txn (NAK) 01 FF FD FD BC BC ... >>> 64 B OUT txn [65 POLL] 01 FF FD FD BC BC F9 A8 ... >>> 64 B OUT txn 8F CC BF 87 52 A9 BB 3C 40 DE 41 01... >>> 64 B OUT txn 2D D3 7E 2D 74 2B 6A 19 99 A5 54 56 ... >>> 64 B OUT txn 5B CD E4 E5 54 94 3B 36 A9 ED 55 ... >>> 64 B OUT txn 43 AE 04 1C FC 05 0D 09 FF 02 97 ... >>> ... >>> But at the 321st packet, I have a strange 55bytes packet, >>> 64 B OUT txn F2 F6 1E 6B E8 A4 12 21 D8 03... >>> 55 B OUT txn 90 D8 F8 0D C2 1C A3 6A 4A 43... >>> 64 B OUT txn (NAK) 7E CB 9C 65 57 EC A3 FF... >>> ...that stalls the pipe. >>> Is there a known limitation in the transfer size? What can make the OS >>> (Mavericks in this case) suddenly send 55 bytes instead of 64? >>> Thanks in advance >>> Eric Gorouben >> >> -------------- next part -------------- > > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Usb mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/usb/archive%40mail-archive.com This email sent to [email protected]
