FX3: how to process the CYU3P_USBEP_SS_SEQERR_EVT endpoint event

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

cross mob
ThCo_999361
Level 1
Level 1

We are using the FX3 in a camera application, with firmware based on the AN75779 application, built using the SDK 1.3.4. The product has been shipping for well over a year now.

We get occasional reports from customers of the video stream from the camera not starting in USB 3.0. We have identified a particular host device used with our camera that this no video case happens infrequently. We have successfully reproduced it in house. When the no video occurs we get a CYU3P_USBEP_SS_SEQERR_EVT on the video IN endpoint when we start the stream. I could not find any example in the various FX3 projects provided by Cypress on how to respond to this error event. I did try calling CyU3PUsbStall (epNum, CyTrue, CyFalse) for this SEQERR_EVT, but that did not clear the condition.

How does one process the CYU3P_USBEP_SS_SEQERR_EVT endpoint event?

Thanks in advance for your help on this.

Tom

0 Likes
25 Replies
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello Tom,

CYU3P_USBEP_SS_SEQERR_EVT event : Sequence number error detected during endpoint data transfer.

Please confirm are you getting  CYU3P_USBEP_SS_RESET_EVT after multiple CYU3P_USBEP_SS_SEQERR_EVT event

If you are getting   CYU3P_USBEP_SS_RESET_EVT , you can handle this event as done in GpifToUsb example of the SDK. The CYU3P_USBEP_SS_RESET_EVT is handled by CyU3PUsbStall (epNum, CyTrue, CyFalse). On identifying the endpoint stall, the host application should issue CLEAR_FEATURE request. This request should be handled in the firmware as done in GpifToUsb example

Snippet from GpifToUSb firmware

     if ((bTarget == CY_U3P_USB_TARGET_ENDPT) && (bRequest == CY_U3P_USB_SC_CLEAR_FEATURE)

                && (wValue == CY_U3P_USBX_FS_EP_HALT))

        {

            if (glIsApplnActive)

            {

                if (wIndex == CY_FX_EP_CONSUMER)

                {

                    CyU3PUsbSetEpNak (CY_FX_EP_CONSUMER, CyTrue);

                    CyU3PBusyWait (125);

                    CyU3PDmaChannelReset (&glDmaChHandle);

                    CyU3PUsbFlushEp(CY_FX_EP_CONSUMER);

                    CyU3PUsbResetEp (CY_FX_EP_CONSUMER);

                    CyU3PDmaChannelSetXfer (&glDmaChHandle, CY_FX_GPIFTOUSB_DMA_TX_SIZE);

                   CyU3PUsbStall (wIndex, CyFalse, CyTrue);

                    CyU3PUsbSetEpNak (CY_FX_EP_CONSUMER, CyFalse);

                    isHandled = CyTrue;

                    CyU3PUsbAckSetup ();

                }

Regards,

Rashi

Regards,
Rashi

Rashi,

I see one, maybe two, CYU3P_USBEP_SS_SEQERR_EVT events when the video stream does not start. I do not see any CYU3P_USBEP_SS_RESET_EVT events when I get the CYU3P_USBEP_SS_SEQERR_EVT.

We previously added the code from the GpifToUsb example to handle CYU3P_USBEP_SS_RESET_EVT events and the CLEAR FEATURE. That is working correctly.

Tom

0 Likes

Hello Tom,

Can you try handling CYU3P_USBEP_SS_SEQERR_EVT same as the  CYU3P_USBEP_SS_RESET_EVT is handled in GpifToUsb Example.

The third parameter of the API CyU3PUsbStall is toggle which if  set to CyTrue Clear the data toggles in a Clear Stall call (i.e. when second parameter passed in CyFalse)

CyU3PUsbStall (epnum, CyTrue, CyFalse); - called when the CYU3P_USBEP_SS_SEQERR_EVT event occurs

CyU3PUsbStall (wIndex, CyFalse, CyTrue); should be called  on receiving CLEAR_FEATURE request from the host

Regards,

Rashi

Regards,
Rashi
0 Likes

Hello Rashi,

I tried this suggestion, but it did not fix the no video issue. Do you have any other ideas?

Thanks,

Tom

0 Likes

Hello Tom,

Please probe  the USB lines when you get the CYU3P_USBEP_SS_SEQERR_EVT error and the endpoint is halted. 

You can take this traces using Lecroy USB Analyzer and share it here.

Regards,

Rashi

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

Rashi,

I was not able to get a capture with the Lecroy, but I did get a capture using the Beagle 5000. Attached. When I get the SEQERR the video stops. That is around index 913869.

Regards,

Tom

0 Likes

Hello Tom,

Thank you the traces.

I tried to open .tdc file with AllCapture software but it says this in not the full project.

Can you share all the files of the project or let me know the software to open .tdc files

Regards,

Rashi

Regards,
Rashi
0 Likes

Rashi,

I used the Total Phase Data Center (v6.73.007) with the Beagle 5000 to capture the data. I downloaded back the zip file and was able to extract and load the .tdc file with Total Phase Data Center without any problems.

Here is a link to the Total Phase Data Center:

https://www.totalphase.com/products/data-center/

Regards,

Tom

0 Likes

Hello Tom,

I have gone through the trace you shared.

There is a ACK TP which is not expected from host , since we set EOB=1, due which the error. But later the data transfer recovers

ack.PNG

I have seen that the device sends the stall . Please confirm that this stall is called when the seq_err occurs

stall.PNG

After the stall is sent , the host should send the clear feature request which is not seen in the trace.

Please check that host application sends clear feature request

Regards,

Rashi

Regards,
Rashi
0 Likes

"On identifying the endpoint stall, the host application should issue CLEAR_FEATURE request" How does a C# host detect that?

0 Likes

Hello,

The UsbdStatusString() is member of CyUsbDevice class

The UsbdStatusString method returns a string that represents the UsbdStatus error code contained in stat. The return string can be Success, pending, stalled or error.

When this return status is stalled, the host application needs to sends the clear feature request

Regards,

Rashi

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

Rashi,

The duplicate ACK TP from the host results in the FX3 sending an NRDY followed by an ERDY. I looked in the statistics that the TPDC trace and there were 1791 NRDYs and 1791 ERDYs on EP3 in the 1.5 seconds that video flowed before the FX3 sent the STALL. The host seems to regularly send duplicate ACKs.

The STALL in the trace is not from my processing of the CYU3P_USBEP_SS_SEQERR_EVT - I don't generate a STALL on that event. I tried that in the past working on this issue and found that STALL did not correct anything.

The STALL in the trace is from my processing of a CYU3P_USBEP_SS_RETRY_EVT that I get prior to getting the CYU3P_USBEP_SS_SEQERR_EVTs. I did the STALL based on the example project in the SDK /basic_examples/cyfxbulksrcsink/cyfxbulksrcsink.c where the CYU3P_USBEP_SS_RETRY_EVT is used to generate a STALL. After researching what causes this retry event, I don't think a STALL is the proper response. I plan on changing my code to just log that event.

I looked in the TPDC trace I previously sent you for RETRYs. There is one at index 913927 (SeqNum=28) and another at 914058 (SeqNum=8). The original Data Transaction for this second retry is at index 914046. Upon looking at this packet closely, while the header has DataLength of 1024 bytes, it appears that 0 bytes of payload were sent out. Thus the retry request from the host for SeqNum = 8. Since the trace shows no payload, makes me think there is some memory use issue.

The "Unexpected" Link Credits in the trace seem odd too - I haven't seen them with other hosts.

I loaded my modified FX3 code where I don't generate a STALL for the CYU3P_USBEP_SS_RETRY_EVT. I took another trace of the USB transactions. I see five RETRYs followed by an NRDY, then ERDY, then no data transfer. I've uploaded this new TPDC trace.

The following index/transaction list include a sequence with RETRYs and data packet length issues in that new trace:

847564 Data, seq=15

847573 ACK seq=15, RETRY

847575 Data, seq=16

847580 Data, Length error, seq=17

847585 Data, Length error, EOB, seq=15

847590 Data, seq=16

847597 ACK seq=16

847601 Data, Length error, seq=17

847606 ACK seq=17

847614 Data, Length error, EOB, seq=18

847618 NRDY

847622 ACK seq=18

847626 ACK seq=18, RETRY

no more data transfer

It is disconcerting that there appears to be some memory corruption going on here.

Regards,

Tom

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

Hello,

Thank you for the update.

Can you just handle the CYU3P_USBEP_SS_RESET_EVT, check if this comes (as it comes after multiple retry), in the firmware and stall the endpoint

After that the host application should sends the clear feature request. This request clear feature should be handled in the firmware by clearing the stall as done i GPIFtoUSB example. When the stall condition is being cleared (in Clear feature handler) , the data toggles for the endpoint can also be cleared so this can be used to solve the issue of seq error

Please take the usb traces when this is executed ans share the traces meanwhile i will go through the new traces you shared in the previous response

Please refer the attachment. If possible try with different host and take the traces

Regards,

Rashi

Regards,
Rashi
0 Likes

Rashi,

The FX3 code used for the trace I sent you yesterday only handles the CYU3P_USBEP_SS_RESET_EVT - it ignores the other endpoint events.

I have run this FX3 code against a Windows10 laptop and a MacBook Air. Both respond properly to the STALL from the FX3. I did not bother tracing that.

The host that is not respond to the STALL from the FX3 is an Asus Chromebox running Google Hangouts.

Tom

0 Likes

Hello Tom,

From the traces shared in previous response i observed that the ACK TP seq num and Data packet seq num are not same which is a problem.

Also when there is ACK TP with retry, the data transaction should start with the same seq num (as ACK TP with retry)

Please confirm that the same problems are seen with the every host you mentioned

1)Windows10 laptop

2)MacBook Air and

3) Asus Chromebox

Regards,

Rashi

Regards,
Rashi
0 Likes

Hi Rashi,

I am only seeing the video freeze problem with the Asus Chromebox.

I've streamed video from the FX3 camera to a Windows10 laptop and MacBook Air for up to 72 hours with no video freezes.

I did notice the sequence numbers out of sync.

On RETRYs, I noticed the host sometimes would ask for a sequence number more than 1 back. In those instances upon inspecting the payload for the original packet vs the re-transmitted packet, the data was different. That is not right. Here is an example:

pastedImage_1.png

Index 847566 is a data payload for data packet with SegNum=15. Index 847573 is an ACK of SeqNum=15 with RETRY. Index 847587 is the data payload for the resend of SeqNum=15; that payload does not match the original payload at 847566. It looks like the FX3 is not handling RETRYs properly.

Tom

0 Likes

Hello Tom,

Index 847566 is a data payload for data packet with SegNum=15. Index 847573 is an ACK of SeqNum=15 with RETRY. Index 847587 is the data payload for the resend of SeqNum=15; that payload does not match the original payload at 847566. It looks like the FX3 is not handling RETRYs properly.

>> There is a possibility that DP sent with seq15 (847566) is corrupted on the bus due to which there is ACK TP SeqNum=15 with RETRY and the data sent ( 847587) the next time is correct data. Is there any way you can confirm the data sent the first time with seq 15 is correct

If the first time data sent is corrupted and this is the reason for RETRY, the Retry handling by FX3 is done correctly

Regards,

Rashi

Regards,
Rashi
0 Likes

Rashi,

I don't have a way to determine if the payload in the initial transmission of a packet that is subsequently flagged for a RETRY is corrupted. From the statistics in the TPDC sniffer trace, there is no indication of CRC errors.

The video displayed in Google Hangouts is distorted when this happens - lines in it appear out of order. I don't have any way for a RETRY to trigger a capture of the video.

The FX3 Technical Reference Manual (Spec No.: 001-76074 Rev *D) in section 10.13.1 (Engress EEPM) talks about some software intervention when there is a retry. I looked through the USB software provided in the SDK for USB APIs, and did not find any function looks like handles the retry processing. Is there some processing I need to do in my application for this?

Regards,

Tom

0 Likes

Hello Tom,

looked through the USB software provided in the SDK for USB APIs, and did not find any function looks like handles the retry processing. Is there some processing I need to do in my application for this?

>> This register can be read using CyU3PReadDeviceRegisters API (refer to bulksrcsink example for using this API). Please let me knwo the register value when the video freezes.

>> You can also read this register PROT_EPI_CS1 (section 10.16.11 of FX3 TRM).

For the addresses of these register refer to FX3 TRM.

Regards,

Rashi

Regards,
Rashi
0 Likes

Rashi,

For the CYU3P_USBEP_SS_RETRY_EVT, I see one of the following two values reading PROT_EPI_CS1[EP3]

0xe003350c = 0x1e900701

0xe003350c = 0x1e902701

and the following for EEPM_CS

0xe0031c00 = 0x3003000

For the CYU3P_USBEP_SS_SEQERR_EVT I get the following when reading PROT_EPI_CS1[EP3]

0xe003350c = 0x1e906701

and the following for EEPM_CS

0xe0031c00 = 0x3003000

For the CYU3P_USBEP_SS_RESET_EVT I get the following when reading PROT_EPI_CS1[EP3]

0xe003350c = 0x1e902701

and EEPM_CS varies

0xe0031c00 = 0x3003007   in one capture

0xe0031c00 = 0x300f007    in a different capture

Please advise if you need additional register dumps.

Regards,

Tom

0 Likes

Hello Tom,

As per our discussion, please share the trace when the sequence error is handled from the firmware just to see the response from the host

Regards,

Rashi

Regards,
Rashi
0 Likes

Hello Tom,

From the traces this is what is observed

1) At 847615, data packet is sent with EOB set.

2) NRDY is sent at 847619 by Fx3.

3) ERDY is sent only at 847633. After this again Ack TP with Seq 18 is sent without retry bit set – but data with seq 18 was already sent at 847615.

This doesn't seem to be correct from the host side. this can be a reason which might have caused the problem

Regards,

Rashi

Regards,
Rashi
0 Likes

Rashi,

If you go back a little bit in the trace, the FX3 does not send a proper packet.

1) At 847601 a data packet (Seq 17) is sent by the FX3 where the header has a length of 1024, but the captured length is 1022

2) At 847610 an Ack TP for Seq 17 is sent by the host

3) At 847615 a data packet (Seq 18) is sent with data payload of length 1024, but no payload is captured

Why does the FX3 send this malformed packet?

Tom

0 Likes

Hello,

Yes, Seq 18 data packet only send Data header and no payload.

Please confirm that  CYU3P_USBEP_SS_RESET_EVT)/  CYU3P_USBEP_SS_SEQERR_EVT event is handled in the firmware while the trace was captured (ChromeBox_video_freeze_20200325.tdc.zip). Please refer to GpifToUsb example for reference.

If not, please handle these events by stalling that endpoint and capture the usb trace. So that we can check whether the endpoint is stalled or not.

Regards,

Rashi

Regards,
Rashi
0 Likes
WGT_4383351
Level 5
Level 5
First like received

What is happening here? I asked a side question here and now you begin to discuss topic that is not very related to my side question...Did my side question trigger more discuss about the original question here?

0 Likes