mirror of https://github.com/ARMmbed/mbed-os.git
Merge pull request #414 from mjrgh/patch-1
Fix KL25Z connect problem with some USB 3.0 hostspull/428/head
commit
ddc5340e3a
|
@ -187,7 +187,27 @@ bool USBDevice::controlOut(void)
|
||||||
/* Check we should be transferring data OUT */
|
/* Check we should be transferring data OUT */
|
||||||
if (transfer.direction != HOST_TO_DEVICE)
|
if (transfer.direction != HOST_TO_DEVICE)
|
||||||
{
|
{
|
||||||
return false;
|
#if defined(TARGET_KL25Z) | defined(TARGET_KL46Z) | defined(TARGET_K20D5M) | defined(TARGET_K64F)
|
||||||
|
/*
|
||||||
|
* We seem to have a pending device-to-host transfer. The host must have
|
||||||
|
* sent a new control request without waiting for us to finish processing
|
||||||
|
* the previous one. This appears to happen when we're connected to certain
|
||||||
|
* USB 3.0 host chip set. Do a zeor-length send to tell the host we're not
|
||||||
|
* ready for the new request - that'll make it resend - and then just
|
||||||
|
* pretend we were successful here so that the pending transfer can finish.
|
||||||
|
*/
|
||||||
|
uint8_t buf[1] = { 0 };
|
||||||
|
EP0write(buf, 0);
|
||||||
|
|
||||||
|
/* execute our pending ttransfer */
|
||||||
|
controlIn();
|
||||||
|
|
||||||
|
/* indicate success */
|
||||||
|
return true;
|
||||||
|
#else
|
||||||
|
/* for other platforms, count on the HAL to handle this case */
|
||||||
|
return false;
|
||||||
|
#endif
|
||||||
}
|
}
|
||||||
|
|
||||||
/* Read from endpoint */
|
/* Read from endpoint */
|
||||||
|
|
Loading…
Reference in New Issue