Cypress USB3 4603 HX3 DVK Credit Issue

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.
MoNa_2346666
Level 1
Level 1

Has anybody seen an issue with Cypress USB3 4603 HX3 DVK "Rev C" re Rx Header Buffer Credit per USB3.1 Standard?

Specifically, in our system, I'm seeing the hub's upstream port issues an extra credit (5 instead of 4) when it receives 4 back-to-back header packets, and thus violating the Standard.  Please see the attached picture where packets 522655, 56, 57, 58 are sent to the hub and the hub sends the required four credits plus the extra credit at packet 522667.

I'm speculating the hub may have a corner-case issue around having 4 back-to-back packets.

Thanks,

Mohsen

0 Likes
1 Solution

Hi Mohsen,

As discussed on the case, this seems to be a corner case that wasnt seen in the our compliance tests. The USB 3.1 Specification does not clearly indicate the expected behaviour when this occurs and since we dont see any change in the packet sequence and hence data loss, we can conclude that it doesnt lead to any error condition. Please implement the existing workaround in your software since we cant fix this in the hub firmware to ensure there arent any functional failures.

Best Regards,

Sananya

View solution in original post

0 Likes
5 Replies
Sananya_14
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hi Mohsen,

We're checking on the issue; could you please mention if this is seen every time 4 header packets are received and provide the complete trace if possible?

Best Regards,

Sananya

0 Likes
lock attach
Attachments are accessible only for community members.

Hi Sanaya,

So far, all the occurrence I have seen are on 4 header packets credit pending with the header packets being back-to-back.

I have attached a short trace for your reference. In this trace, you can go to the trigger point and the extra credit is @packet 295

Thanks,

Mohsen

0 Likes

Hi Mohsen,

We havent seen this issue in the past while doing the compliance tests or with the DVK. If the host receives this extra credit for no valid header packet, the link should have been put in Recovery state. Do you see any functional failure after this occurs?

Since the trace captured shows only one such instance, could you kindly capture a more complete trace? This would help us analyze the sequence better.

Best Regards,

Sananya

0 Likes

Hi Sanaya,

The issue I"m reporting is clearly a corner case that the Compliance tests, which your design has been tested against, lack the specific scenario.  I wonder if your engineering team can look into their own verification and coverage results to determine if this corner case has ever been covered.  For your information, we have not seen this issue on many hosts/system configurations, but only certain hosts/system configurations show the issue.

When you say the link should go to Recovery for this extra credit, my design is currently not forcing the link into Recovery as I have not seen such direction in the USB3.1 Standard. Could you please point to the Section in the Standard that instructs the link to go into Recovery for receiving extra credit?  My current design only reports and takes preventive actions when facing the above extra credit to avoid any functional failure.

Unfortunately, these extra credits do not happen as often and, as the result, I cannot provide a trace that shows more than one instance of the issue in one trace. In the above, I've already included traces for two such sequences, and I hope that should be sufficient for any investigation that Cypress needs to carry out.

Kind Regards,

Mohsen

0 Likes

Hi Mohsen,

As discussed on the case, this seems to be a corner case that wasnt seen in the our compliance tests. The USB 3.1 Specification does not clearly indicate the expected behaviour when this occurs and since we dont see any change in the packet sequence and hence data loss, we can conclude that it doesnt lead to any error condition. Please implement the existing workaround in your software since we cant fix this in the hub firmware to ensure there arent any functional failures.

Best Regards,

Sananya

0 Likes