Are you talking about the default bootloader present in the FX3 or second stage bootloader?.

Thanks,

sai krishna.

"Right now there is a concurrency issue in processing of Control transfers between FX3 hardware and setup callback (as this is already mentioned in FX3 documentation as well). When new SETUP packet arrives then the hardware switches to serve this new request while software continues to serve previous (cancelled) one, supplying hardware with expired data this way. Result is chaos - wrong data read/written, errors, transfer hanging, etc."

Can you tell me where this is documented?

It appears I have a similar problem:

Under windows8 when I queu-up 100 bulk transfer requests and requeue every finished request in a loop in one thread and sent control read request with a data stage in another thread. I can get the firmware in a state where it doesn't respond anymore. In netmon I see the control request timeout (5 seconds) and a reset to the endpoint issued by Usbxhci. This gives me the idea that the entire device doesn't respond anymore. Further I can't recover until reprogramming the device.

I don't see this behaviour when sending control writes (any type, i.e. with or without data) or control read without data stage (= reading zero length).

Hi,

which errors do you get on host side? Is it USBD_STATUS_XACT_ERROR?

thanks,

lumpi

g_CtrlEndpt->XferData(ctrlbuf, ctrllen) return false due to the timeout. Which is standard 5 seconds when I don't set it myself. When I set it myself the documentation on setting the timeout states it will be multiples of 1000ms, which is confirmed when looking at the netmon logs.

Both g_CtrlEndpt->NtStatus, g_CtrlEndpt->UsbdStatus return 0.

Has anyone information on where to find information in the documentation on how the hardware handles the control transfer and the relation with the SW callback?

Just to let you know:

my problem was solved when linking with the 1.2.1 API

I can completely saturate the link with control transfers and do a bulk transfer at the same time.

Each control READ transfer takes a around 0.5ms.

I include here the handling:

CyBool_t
CyFxSlFifoApplnUSBSetupCB (..)

..

 if (bType == CY_U3P_USB_VENDOR_RQT)

..

case CY_FX_RQT_CONTROL_READ_TEST:  // Custom Vendor Command

      if (wLength == 0){   // For debugging/robustness we handle zero bytes reads
      CyU3PUsbAckSetup();

       // status = CY_U3P_SUCCESS;
       break;  // Status
      }

    CyU3PMemSet (glEp0Buffer, 0, sizeof (glEp0Buffer));
 

      status = CyU3PUsbSendEP0Data (wLength, glEp0Buffer);
      if (status != CY_U3P_SUCCESS)
       break;

      break;
 

Attached a netmon3.4 log on windows 8

Refer to http://blogs.msdn.com/b/usbcoreblog/archive/2012/08/07/how-to-trace-usb-3-activity.aspx

Hi dtromp_nl,

thanks for sharing your solution. I can not completely follow...

Was your solution now to update to FX3 SDK version 1.2.1 or was it your inlcluded handling or both?

Regards to your handling, if the wLength is 0, then you call CyU3PUsbAckSetup() and after that you call additional CyU3PUsbSendEp0Data (0, gl_ep0Buffer). ???

regards,

lumpi

Hi,

>Was your solution now to update to FX3 SDK version 1.2.1 or was it your inlcluded handling or both?

Yes that was all. I included the handling to enable you to interprete the results in the .png

>Regards to your handling, if the wLength is 0, then you call CyU3PUsbAckSetup() and after that you call additional CyU3PUsbSendEp0Data (0, gl_ep0Buffer). ???

No, the break prevents reaching the CyU3PUsbSendEp0Data. Since the status is still CY_U3P_SUCCESS, the CyFxSlFifoApplnUSBSetupCB  callback will return CyTrue to indicate all was handled (i.e. we don't need to stall the endpoint).

Hi,

thanks for the answer, now I understood.

regards,

lumpi