|
From: Christian J. <ja...@st...> - 2013-11-20 09:24:46
|
Hi Toby, On 11/19/2013 07:20 PM, Toby Gray wrote: > On 19/11/13 10:05, Christian Jäggi wrote: >> Hi Toby, > > Hi Christian, > >> As I understand either the libusbx-call libusb_bulk_transfer() OR >> libusb_fill_bulk_transfer() is calling the kernel-wrapper-function >> UkwIssueBulkTransfer, correct (perhaps just one of them)? > > Yes, you are almost correct. Calling libusb_bulk_transfer() or > libusb_submit_transfer() will end up with a call to UkwIssueBulkTransfer. > >> >> What's more confusing now, the one eval board running usb 1.1 full speed >> is working (slowly but...) with this kind of transfers. > > That's good news. I assume the slowness is just due to only running at > full speed? > That was my assumption as well. It is satisfying indeed. >> As soon as I >> switch to the other board with a high speed USB interface The following >> error message appears: >> >> libusbx: error [] UkwIssueBulkTransfer failed: error 8 >> log: o3000_dummy_string: : Unknown error (-11) >> >> log: o3000_dummy_string: : submitted transfer 004F55C0 >> >> libusbx: error [] UkwIssueBulkTransfer failed: error 8 >> log: o3000_dummy_string: : Unknown error (-11) >> >> ... and so on for each transfer handler to be set up. >> >> As I read in the documentation, that might be a memory problem? > > That sounds like a reasonable assumption as 8 is ERROR_NOT_ENOUGH_MEMORY. > >> But >> where exactly? A buffer problem? > > It depends. Without more logging it's hard too tell. The ceusbkwrapper > driver supports debug zones, so if you could enable all of the zones and > grab the debug output that'd be quite helpful in working out where the > failure is occurring. If you've never heard of debug zones then this > page describes how to use them: > http://blogs.msdn.com/b/ce_base/archive/2006/12/18/debug-messages-and-debug-zones-in-windows-ce.aspx > > The most interesting debug zones for ceusbkwrapperdrv are 0 (errors), 1 > (warnings) and 5 (transfer lifetime). Debug zone 5 is only enabled in > debug builds unless you edit drv/drvdbg.h. > > The most likely candidate would be one of the validation checks in this > file: > https://github.com/RealVNC/CEUSBKWrapper/blob/master/drv/Transfer.cpp#L133 > > What direction are you bulk transfers, how large is each individual > transfer and how many concurrent transfers do you have? > > The most likely cause of the error would be the CeOpenCallerBuffer or > CeAllocAsynchronousBuffer calls failing, which are used to map > user-space memory into the kernel driver. This could happen if you pass > a pointer to invalid memory or possibly if you are attempting to map too > much memory in one go. > OK I will try to recompile and build a new platform with debug output. As for the other questions mentioned above: We use 2 bulk in endpoints. 1 endpoint uses 10 concurrent transfers with a size of 200KBytes each (so all in all 2 MBytes buffer). We've also tested it with 1MByte or 5MByte for each transfer (equals 10MByte or 50MBytes respectively). The other endpoint buffer consists of just one transfer with the size of 16384Bytes. Interestingly, this one doesn't cause any errors and is working as expected. Any clue or hint for that? Thanks as always! k regs, Christian > Regards, > > Toby > > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > > > > _______________________________________________ > libusb-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel > |