Eric, I've run out of ideas. Have you tried USB Tracer? (https://developer.apple.com/library/mac/qa/qa1370/_index.html#//apple_ref/ doc/uid/DTS10003388) Maybe it can give you a clue why the system doesn't like your requests. Stuart
On 3/25/15, 5:51 AM, "Eric Gorouben" <[email protected]> wrote: >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]
