Cancelling of Control transfer causes following Control transfers to fail.

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable
    Cancelling of Control transfer is very common operation. For example while user terminates the program, typically all pending I/O operations are cancelled. Therefore this case should be handled properly in device.   
   
        
   
    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.   
   
        
   
    As cancelling is so common, then I expect that fixing this could have high priority. Assuming that quick bullet-proof  implementation is impossible with current hardware (as it typically tends to be) then even polling "new SETUP packet arrived" flag in SW and failing CyFx3BootUsbDmaXferData, CyU3PUsbSendEP0Data, etc., functions as soon as possible would be a great improvement.   
   
        
   
    BTW, is there a function for flushing/resetting Control Pipe DMA in Boot Loader API? This functionality is needed for recovering from situations where not all data are transferred, especially when CyFx3BootUsbDmaXferData will be fixed to return error when new SETUP packet arrives.   
   
        
   
    Thanks,   
   
    K   
0 Likes
9 Replies
Anonymous
Not applicable

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

   

Thanks,

   

sai krishna.

0 Likes
Anonymous
Not applicable
    Hi,    
     
I am talking about secondary boot loader and application software. There I have verified the problem exists both in FX3 BOOT API and FX3 API.  But if default boot loader (i.e. BootROM)  bases on same APIs, then most probably it's in there as well.    
     
Regards,    
K   
0 Likes
Anonymous
Not applicable

"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).

0 Likes
Anonymous
Not applicable

Hi,

   

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

   

thanks,

   

lumpi

0 Likes
Anonymous
Not applicable

   

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?

0 Likes
Anonymous
Not applicable

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

0 Likes
Anonymous
Not applicable

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

0 Likes
Anonymous
Not applicable

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).

0 Likes
Anonymous
Not applicable

Hi,

   

thanks for the answer, now I understood.

   

regards,

   

lumpi

0 Likes