- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I have FX3 device with the "USBIsoSourceSink" exmeple,
I can see in Lecroy trace that i have delay of ~130ns between Data packets in burst mode in "IN End Point"
But the USB 3.2 Spec is Max 100 ns delay
I Attached the trace and also take screen shut,
Is there a way to decrees the delay between data packet in the FX3 device code?
Thanks,
EliW.
Solved! Go to Solution.
- Labels:
-
USB Superspeed Peripherals
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi EliW,
If your application makes use of only one IN endpoint, then you can try to add the following line of code after the API CyU3PDmaChannelSetXfer () is called inside the function CyFxIsoSrcSinkApplnStart ():
// Set LNK_CONF.EPM_FIRST_DELAY = 10
*((uvint32_t *)0xe0033000) = ((*(uvint32_t *)0xe0033000) & 0xFFFF0FFF) | 0x0000A000;
The above code will set the register field LNK_CONF.EPM_FIRST_DELAY to 10. It is recommended not to drop the value of this field below 10 as no testing has been done with lower values.
We tried the above modification at our end and found that the delay between the packets were around 80ns. Please try this at your end and let us know if you face any issues. I have attached a snapshot of the trace captured at our end along with this response.
Jayakrishna
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Please let us know the following so that we can understand the issue better:
1. Are you testing on a custom hardware or are you making use of Superspeed explorer kit for the tests? If you have not used Superspeed explorer kit for testing, then is it possible to test on Superspeed explorer kit?
2. Is the delay of ~130ns consistent? Or does it meet the timing mentioned in USB specification at times?
Jayakrishna
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
1. Yes im using the Superspeed explorer kit.
2. The delay is allways above 100 ns of the USB 3.2 spec, around 130 ns sometimes lower but not lower then 100 ns.
Thanks,
EliW
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello EliW,
We captured a trace using the same setup as mentioned by you in the previous responses. Please find the snapshot of the trace below:
Please find a snapshot of a section of USB 3.1 specification given below:
As mentioned in the USB 3.1 specification, these timings are valid when the host/device has nothing else to send on its downstream or upstream link. As you can see from the snapshot of the trace shared above, there are link commands issued in between the data packets. So, this could be the reason for the deviation from the specification.
Jayakrishna
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I don’t think it’s the problem hear,
If you look at my trace, i have shut down all power management (UX mode)
So it won't send LGO u1 from the host and there is still a delay between packets,
If you look at the time stamp in the red Circle the problem seems to be the delay between the idle symbol to the next Data packet
2240-2124 = 116 ns of delay
If you look at the next screen shut, you will see OUT transection from Host to FX3
The delay between idle to data packet is
2136-2124 = 12 ns of delay
So I think the problem is in that direction.
Thanks,
EliW.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Another example of Camera device that use ISOC traffic
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Does this camera also make use of FX3?
Jayakrishna
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
No, its gaming camera.
https://www.razer.com/streaming-cameras/Razer-Kiyo-Pro/RZ19-03640100-R3U1
Thanks,
EliW.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi EliW,
Please let us know on which OS you are testing? Is it on Windows 10? If yes, did you disable the LGO_Ux by disabling the selective suspend in power management?
Jayakrishna
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
yes, on win 10 and win 11, have the same results
did you disable the LGO_Ux by disabling the selective suspend in power management? - Yes
Thanks,
EliW.
- 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
Hello EliW,
We are checking on the issue at our end. I will update the thread as soon as we reproduce the issue at our end.
Also, can you let us know if this delay is causing any issues in data transfers?
Jayakrishna
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
can you let us know if this delay is causing any issues in data transfers? - Sure
When there is delay in packet, the final result is "missed service"
Missed service definition is:
it happen because that in one frame we have 125 us,
And when we try to burst 3x16 = 48 data packet in one frame the delay between packet makes the last packet exceed the 125 frame limitation, causing missed service.
The problem gets even worse when using more FX3 devices under HUB.
By the way, from the trace screen shut that you sent earlier, I can see that the problem reproduce at your end,
If you look at the trace you will see "warning" made by Lecroy SW.
it indicate because when the packet left the FX3 device with the "delay bit" on, meaning that the device know about the delay is out of USB 3.2 Spec.
Thanks,
EliW.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi EliW,
Please try the following modifications in the default example project and let me know the results:
1. Please increase the clock speed by using the following modification:
2. Soon after configuring the consumer endpoint, call the API CyU3PUsbEPSetBurstMode () as shown below:
3. Please let me know if you have a shorter and certified USB cable. If yes, then please test with the shortest cable that you have.
Currently, I do not have access to the analyzer for testing at my end. So, please perform the above tests at your end and let me know if there any changes in the delay.
Jayakrishna
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Thanks for the Help,
I tried to put the code that you sent me, it didn’t help, still there is delay,
Im using 30cm lecroy 10Gbps certified cable.
Is there parameters to change to increase the clock speed? Because I just copy the code into the example.
Thanks,
EliW.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi EliW,
The settings that I shared in my previous response will make the FX3 device to use the maximum possible clock speed. You cannot increase it any further.
I understand that you face the delay even after performing the modifications that i recommended in my previous response. Can you please let me know if the delay has increased or decreased? Please let me know this information so that I can check on this issue internally.
In addition to this, can you please test by building the firmware after removing the second modification that I mentioned in my previous response? Please let me know the results after this test too.
Jayakrishna
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
It looks like the same delay, can't see major change in there,
Also the same when I change the second line I add,
"//apiRetStatus = CyU3PUsbEPSetBurstMode (CY_FX_EP_CONSUMER, CyTrue); // **Add for burst mode"
Just to see that my change are affecting something, I change some value to see if the FX3 will work,
And when I change some parameters I saw different behavior so the change in the code is working.
Thanks,
EliW.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi EliW,
Can you please let me know if you have tested using debug build or release build? If you have tested with debug build, then can you please check with release build and let us know if you find any improvements?
Jayakrishna
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
i have tested on release build.
there is still no improvements.
Thanks,
EliW.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi EliW,
Thank you for the updates. The issue is reproducible at our end too. I am checking internally on this issue. I will update the thread as soon as I get a response internally.
Jayakrishna
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi EliW,
If your application makes use of only one IN endpoint, then you can try to add the following line of code after the API CyU3PDmaChannelSetXfer () is called inside the function CyFxIsoSrcSinkApplnStart ():
// Set LNK_CONF.EPM_FIRST_DELAY = 10
*((uvint32_t *)0xe0033000) = ((*(uvint32_t *)0xe0033000) & 0xFFFF0FFF) | 0x0000A000;
The above code will set the register field LNK_CONF.EPM_FIRST_DELAY to 10. It is recommended not to drop the value of this field below 10 as no testing has been done with lower values.
We tried the above modification at our end and found that the delay between the packets were around 80ns. Please try this at your end and let us know if you face any issues. I have attached a snapshot of the trace captured at our end along with this response.
Jayakrishna
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
First of all great job, thanks.
It helped redosing the delay between packets,
But the delay bit is still on, can you check why it is still on?
And regarding the "LNK_CONF.EPM_FIRST_DELAY to 10" can we check what is the best value?
If we can get it even lower it will be great, it will help us do stress test.
And again, Thanks.
EliW.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello EliW,
And regarding the "LNK_CONF.EPM_FIRST_DELAY to 10" can we check what is the best value?
>> It is recommended to keep this setting with max. possible value as a means to minimize possibilities of data corruption when transferring data on multiple endpoints. But, if you are using a single IN endpoint only, then it can be reduced to 10. This is the best value and as mentioned in my previous response, it is not recommended to reduce this value below 10.
I will check again internally to see if this value can be reduced and update the thread as soon as I get a response internally.
Jayakrishna
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
the delay bit is still on, can you check why it is still on?
Thanks,
EliW.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi EliW,
Sure, I will check about the DL bit too internally. Can you please let us know if the traces obtained for the custom camera was also captured using the same setup?
Can you please let me know if the missed service error was resolved with the workaround provided in my previous response?
Jayakrishna
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Sure, I will check about the DL bit too internally. Can you please let us know if the traces obtained for the custom camera was also captured using the same setup? - yes
Can you please let me know if the missed service error was resolved with the workaround provided in my previous response? - i still have missed service but less so its better
Thanks,
EliW.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello EliW,
Please refer to the the following snapshot from USB 3.1 specification which mentions about the possible reasons due to which DL bit can be set:
As mentioned above, about the DL bit:
1. This bit can be optionally set by a device. This depends on the way in which the device is implemented i.e different devices can work differently as it is an optional requirement.
2. The DL bit is only relevant for ITPs.
I checked internally and found that by implementation, FX3 can set the DL bit due to the reasons mentioned in USB 3 specification. So, this is the reason for the DL bit to be set in the traces captured using FX3 device.
In order to reduce the delay between the packets, the only option we have is to further modify the EPM_FIRST_DELAY field. But as mentioned before, we have never tested this field with a value less than 10. You can try reducing it a bit further and do sufficient tests at your end to see if there are any issues.
Jayakrishna