- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Are you talking about the default bootloader present in the FX3 or second stage bootloader?.
Thanks,
sai krishna.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
"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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
which errors do you get on host side? Is it USBD_STATUS_XACT_ERROR?
thanks,
lumpi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
thanks for the answer, now I understood.
regards,
lumpi