tMaxBurstInterval in isoc traffic FX3

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

cross mob
lock attach
Attachments are accessible only for community members.
EliW
Level 3
Level 3
25 replies posted 25 sign-ins 10 replies posted

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

 

EliW_1-1644142023275.png

 

 

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.

 

EliW_2-1644142303993.png

 

0 Likes
1 Solution
lock attach
Attachments are accessible only for community members.
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

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.

Best Regards,
Jayakrishna

View solution in original post

26 Replies
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

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?

Best Regards,
Jayakrishna
0 Likes

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

0 Likes
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

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:

JayakrishnaT_76_0-1644292802897.png

Please find a snapshot of a section of USB 3.1 specification given below:

JayakrishnaT_76_1-1644292900877.png

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.

Best Regards,
Jayakrishna
0 Likes

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

EliW_0-1644477538683.png

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.

EliW_1-1644478318174.png

 

 

0 Likes
EliW
Level 3
Level 3
25 replies posted 25 sign-ins 10 replies posted

EliW_0-1644482542793.png

Another example of Camera device that use ISOC traffic

0 Likes
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hello,

Does this camera also make use of FX3? 

Best Regards,
Jayakrishna
0 Likes
0 Likes
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

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?

Best Regards,
Jayakrishna
0 Likes

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.

0 Likes
EliW
Level 3
Level 3
25 replies posted 25 sign-ins 10 replies posted

EliW_0-1644486878977.png

 

0 Likes
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

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?

Best Regards,
Jayakrishna
0 Likes

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:

 

EliW_0-1644599930770.png

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.

 

EliW_1-1644600651532.png

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.

0 Likes
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

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:

JayakrishnaT_76_0-1644903023136.png

2. Soon after configuring the consumer endpoint, call the API CyU3PUsbEPSetBurstMode () as shown below:

JayakrishnaT_76_1-1644903066220.png

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. 

Best Regards,
Jayakrishna
0 Likes

Hi,

Thanks for the Help,

 

I tried to put the code that you sent me, it didn’t help, still there is delay,

EliW_0-1644926203283.png

Im using 30cm lecroy 10Gbps certified cable.

EliW_1-1644926718959.png

Is there parameters to change to increase the clock speed? Because I just copy the code into the example.

 

Thanks,

EliW.

0 Likes
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

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.

Best Regards,
Jayakrishna
0 Likes

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.

0 Likes
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

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?

Best Regards,
Jayakrishna
0 Likes

Hi,

i have tested on  release build.

there is still no improvements.

Thanks,

EliW.

0 Likes
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

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.

Best Regards,
Jayakrishna
0 Likes
lock attach
Attachments are accessible only for community members.
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

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.

Best Regards,
Jayakrishna

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?

EliW_0-1645444671760.png

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.

0 Likes
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

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.

Best Regards,
Jayakrishna
0 Likes

Hi,

the delay bit is still on, can you check why it is still on?

EliW_0-1645607179541.png

Thanks,

EliW.

 

0 Likes
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

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?

Best Regards,
Jayakrishna
0 Likes

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.

0 Likes
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

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:

JayakrishnaT_76_0-1645682775622.png

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. 

Best Regards,
Jayakrishna
0 Likes