Why IN endpoint is always STALLED

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

cross mob
WGT_4383351
Level 5
Level 5
First like received

With Slave/Master example in AN87216, without any data transfer, CyUSBDevice.UsbdStatusString(inEndpoint.UsbdStatus) will returns a stalled state. Is this normal? If so then how to decide when the device is dead?

quote:

"

As an endpoint memory reset will result in some loss of data on the in-flight

endpoint; it is required that the firmware application perform an error recovery on

the corresponding endpoint. This can be done by registering for the

CYU3P_USBEP_SS_RESET_EVT event on all IN endpoints, and performing an

endpoint specific recovery when the event is received. The recommended recovery

procedure is to STALL the endpoint, and then stop and restart the DMA data path

when the CLEAR_FEATURE request is received.

"

When will CLEAR_FEATURE be sent to the device? Is it when inEndpoint.Reset() on the host? But how to decide when to inEndpoint.Reset() if you can't decide whether the device is dead for not if inEndpoint.UsbdStatus will return stalled even the device is not dead?

0 Likes
1 Solution

Hello,

Thank you for the update

As per the connection PC<->extending wire<->4 port hub with a 10cm short tail wire<->two FX3 there is too many connections (which can cause poor link) between device and host.

To debug the problem can you try connecting both the FX3 directly to PC and check the status

Regards,

Rashi

Regards,
Rashi

View solution in original post

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

Hello,

Please confirm that the status  is being checked after calling XferData API /BeginXferData

stall_status.PNG

So after doing the transfers, the status has to be checked and not without transfer. Please try doing some transfer and then check the result.

Please send the snippet of your C# application ,which implements this, for us to confirm

Regards,

Rashi

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

The problem is, although UsbdStatusString after XferData will give SUCCESS if the transfer success, it will still give STALL if there is no ready data and the slave timeout.

Then how can the host application tell between a no data time out STALL or a dead STALL? Since reset the endpoint will stall the host application for seconds, you can only do this when the device is really dead.

0 Likes

Hello,

Please print the value of status and confirm that the code for both cases i.e.

- stall due to time out

- endpoint stall (when the API CyU3PUsbStall is called in error handler)

are same.

When the endpoint is stalled (when the API CyU3PUsbStall is called in error handler) the error code expected is 0xC0000030 USBD_STATUS_ENDPOINT_HALTED

Please refer to this link for the error codes USBD_STATUS (Windows Drivers) | Microsoft Docs

Regards,

Rashi

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

In normal no data receive time out status,

inEndpoint.UsbdStatus=0xc0010000,

I thought they are the same since I only check the result of CyUSBDevice.UsbdStatusString which is both "state=HALTED status=UNKNOWN"

BTW, isn't there some pre defined values in the C# API like:

public const int USBD_STATUS_ENDPOINT_HALTED =0xC0000030;

or the client code have to define these values?

It's common to define an Enum type for such value, for example, inEndpoint.UsbdStatus is better to be a Enum type instead of uint.

0 Likes

Hello,

You can do any way you like.

The bulkloop application directly checks the error code

                    if (inEndpoint.BeginDataXfer(ref cBufs, ref buffer, ref len, ref inOvLap) == false)

                     {

                         // Error Occurred.

                         if (inEndpoint.UsbdStatus == 0xC0000030) // USBD_STATUS_ENDPOINT_HALTED

                         {

                             inEndpoint.Reset();

                             if (inEndpoint.BeginDataXfer(ref cBufs, ref buffer, ref len, ref inOvLap) == false)

                             {

                                 failure++;

                                 Thread.Sleep(10);

                                 continue;

                             }

                         }

So you just need to check the error code that is returned by usbdstatusString

Regards,

Rashi

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

Now the problem is, when use inEndpoint.XferData to receive data from slave, and when it fails (at the same times serial port tells CYU3P_USBEP_SS_RESET_EVT is sent on slave), inEndpoint.UsbdStatus is 0xc0000011 what is this?

Can you provide a reference of all the possible values for inEndpoint.UsbdStatus?

0 Likes
WGT_4383351
Level 5
Level 5
First like received

Does 0xC0000030 only work for BeginDataXfer?

0 Likes
WGT_4383351
Level 5
Level 5
First like received

Experiments shows that

if (inEndpoint.UsbdStatus == 0xc0000011) inEndpoint.Reset();

works after inEndpoint.XferData.

Can you check why not 0xC0000030?

The remaining problem is as my newest post - reset and stall for seconds each a few minutes is not acceptable by end user.

0 Likes

Hello,

Please refer to this link USBD_STATUS (Windows Drivers) | Microsoft Docs which mentions different error codes and their description

Please confirm that you are handling the CYU3P_USBEP_SS_RESET_EVT correctly by calling CyU3PUsbStall API. Please check tha part of the code is executed by putting CyU3PDeviceReset(CyFalsE) in the condition where CYU3P_USBEP_SS_RESET_EVT  is handled.

endpoint_stall.PNG

When CyU3PUsbStall API (source code) is called, ERDY is sent to host so that host can initiate transfer and find that endpoint has been stalled and then send Clear feature request

BeginxferData is asynchronous method of performing transfer while XferDats is synchronous method. You can use either XferData or BeginXferData but you need to confirm that the stall is sent from the firmware

Regards,

Rashi

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

0xC0000011 is USBD_STATUS_XACT_ERROR, why?

Your last post is confusing:

"Please check tha part of the code is executed by putting CyU3PDeviceReset(CyFalsE) in the condition where CYU3P_USBEP_SS_RESET_EVT  is handled." -why?

CyU3PDeviceReset will reset the device and all state will be lost.

Shouldn't I print some information to serial port when handling CYU3P_USBEP_SS_RESET_EVT? That is already done:

pastedImage_0.png

pastedImage_1.png

"When CyU3PUsbStall API (source code) is called, ERDY is sent to host so that host can initiate transfer and find that endpoint has been stalled and then send Clear feature request"

Who will send clear feature reset? Is inEdnpoint.Reste()?

0 Likes

Hello,

0xC0000011 is USBD_STATUS_XACT_ERROR, why?

>>The status code (0xC0000011) is mapped to USBD_STATUS_XACT_ERROR. This XACT error refers to a Transaction Error.

  

         A device driver for a USB device may observe that a USB Transfer to or from the device fails due to a Transaction Error. This error is reported to USB device drivers by the Microsoft USB core driver stack via the USB status code USBD_STATUS_XACT_ERROR. In the USB EHCI specification, the following is the definition of a transaction error:

  

         Transaction Error (XactErr). Set to a one by the Host Controller during status update in the case where the host did not receive a valid response from the device (Timeout, CRC, Bad PID, etc.).

"Please check tha part of the code is executed by putting CyU3PDeviceReset(CyFalsE) in the condition where CYU3P_USBEP_SS_RESET_EVT  is handled." -why?

CyU3PDeviceReset will reset the device and all state will be lost

>> I asked to do this just to check whether the stall is being called when CYU3P_USBEP_SS_RESET_EVT occurs. Now after looking at the debug prints it seems that the CyU3PUsbStall is executed

"When CyU3PUsbStall API (source code) is called, ERDY is sent to host so that host can initiate transfer and find that endpoint has been stalled and then send Clear feature request"

>> inEndpoint.Reset(); needs to be called in the host application when endpoint stall (0xC0000030) is detected

When this request is sent from the host application to FX3, the firmware should clear the endpoint stallstall_1.PNG

Regards,

Rashi

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

Why in my case it is 0xC0000011 instead of 0xC0000030? Does this difference mean anything?

My code is:

pastedImage_0.png

There is no CyU3PUsbSetEpNak and CyU3PUsbSetAckSetup, not sure whether this difference has impact.

0 Likes
WGT_4383351
Level 5
Level 5
First like received

Why in my case it is 0xC0000011 instead of 0xC0000030? Maybe both value should be checked for?

0 Likes

Hello,

I think it is getting confusing. Let's go step by step

Please confirm that  CYU3P_USBEP_SS_RESET_EVT is handled as follow and then check the return value of status when this part of code is executed

endpoint_stall.PNG

When this code is executed and endpoint is stalled the return value of  status should be 0xC0000030.

Please check for this condition in the host application code and check whether this is executed or not. You an put some debug prints when this condition is met to know whether code in the if condition is executed or not. Please don't include 0xC0000011, as of now, to debug the problem

  if (inEndpoint.UsbdStatus == 0xC0000030) // USBD_STATUS_ENDPOINT_HALTED

                         {

                            //Put debug print

                             inEndpoint.Reset();

}

Regards,

Rashi

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

Please check the history of this thread, it is executed and serial debug information is printed. But the what the host get is 0xC0000011.

0xC0000011 + reset() works for the "bad extending cable" environment. There is no 0xC0000030 in this environment. Maybe this environment is not met in your lab and it is a situation the current KBs doesn't cover.

0 Likes

Hello,

Please share the snippet of the C# code where the usbdstatus is being checked.

Regards,

Rashi

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

pastedImage_0.png

This works fine with the bad cable. 0xC0000030  doesn't work since it is always 0xC0000011  when dead.

0 Likes

Hello,

Can you check the same thing is happening with control center by pressing URBSTAT (icon on the top) after transfer is done

I have tried doing it.

This is when data is not ready and host is asking for it. So, this proves by default the status is not "stalled" when data transfer fails

halted.PNG

This is a success data transfer

success.PNG

Please try this with your firmware and control center and share the snippet as i have shared

Regards,

Rashi

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

C0010000 for no data and 0 for success is already verified by the C# program before (talked in some thread)

As you recommended, you need to get the status immediately after the transfer to get 0xC0000011 /0xC0000030, if you already know the device is dead and read the status again like in Control Center, it will be C0010000

0 Likes

Hello,

I am unable to understand the meaning of "device is dead" .Please elaborate your meaning of "device is dead"

Please explain this "This works fine with the bad cable. 0xC0000030  doesn't work since it is always 0xC0000011  when dead."

>>why do you say bad cable?

- Please probe  the USB lines using wireshark and share the .pcap file

- Also let me know check that the program enters "else" condition  in the C# application code you shared. Do you check the value of stReset ?

Please let me know the environment you are working in

- OS version

- Cypress Driver version

- host controller

Regards,

Rashi

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

"device is dead" means what ever you do, it just doesn't respond to bulk IN/OUT anymore, like dead.

"This works fine with the bad cable. 0xC0000030  doesn't work since it is always 0xC0000011  when dead." Means according to my experiments, the above work fine for a bad cable, with which the device will be dead for 0.5~2 times per minuts. When it is dead, the else branch is hit and the endpoint is reset by the C# code and the device is dead for another several seconds (resetting I guess) the it come alive again. Then the device can keep transfering data at >2Gbps for hours, dead 0.5~2 times per minuts, each time stReset is increased by one.

Win10 1903 x64, SDK1.3, host controller is iH77

0 Likes
WGT_4383351
Level 5
Level 5
First like received

The connection is PC<->extending wire<->4 port hub with a 10cm short tail wire<->two FX3

The extending wire doesn't have to be bad, maybe it is just the connection between the extending wire and the tail of the hub degrades the signal with reflections.

The bad link is not between PC and FX3 but PC with the hub, this may be the reason.

0 Likes

Hello,

Thank you for the update

As per the connection PC<->extending wire<->4 port hub with a 10cm short tail wire<->two FX3 there is too many connections (which can cause poor link) between device and host.

To debug the problem can you try connecting both the FX3 directly to PC and check the status

Regards,

Rashi

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

If good cable is used, status will always be 0 since there won't be any deads, not even retries.

Summary: I'v never seen 0xC0000030 here, only 0xC0000011 for bad cable device deadth.

0 Likes

Hello,

usbd_status_endpoint_halted 0xc0000030

A Transfer was submitted to an ENDPOINT the is stalled. or A transaction is routed to an endpoint in the stall (pending) state

The status code (0xC0000011) is mapped to USBD_STATUS_XACT_ERROR. This XACT error refers to a Transaction Error.

 

         A device driver for a USB device may observe that a USB Transfer to or from the device fails due to a Transaction Error. This error is reported to USB device drivers by the Microsoft USB core driver stack via the USB status code USBD_STATUS_XACT_ERROR. In the USB EHCI specification, the following is the definition of a transaction error:

 

         Transaction Error (XactErr). Set to a one by the Host Controller during status update in the case where the host did not receive a valid response from the device (Timeout, CRC, Bad PID, etc.).

There is a possibility that before the endpoint is halted (by the FX3 firmware) the transfer fails (due to bad link or too many interfaces) due to transaction error(0xC0000011) . That is the reason i am asking for USB traces using wireshark to check whether the 0xc0000011 comes after endpoint is halted or before that.

Please refer to response 5 of  this thread Using FX3 USB3.0 with a USB3.0 HUB where similar hardware setup (too many interfaces) is used and the same error is observed. This thread is not answered it is just for your reference

Regards,

Rashi

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

"That is the reason i am asking for USB traces using wireshark to check whether the 0xc0000011 comes after endpoint is halted or before that."

How to decide 0xc0000011 or 0xc0000030 per wireshark trace result? Example:

pastedImage_0.png

This is the trace around the deadth, how to decide?

0 Likes

Hello,

Just this snippet wont help in debugging the problem

Please share the .pcap file (when the "device is dead" or you get 0xc0000011)

If the file size is more attach the .zip file with your response

Regards,

Rashi

Regards,
Rashi
0 Likes

Hello,

We cannot reproduce the issue at our end.

For debugging the issue we would need wireshark traces (.pcap) where endpoint is stalled and the usb status is 0xc0000011.

You can share the traces with this thread

Regards,

Rashi

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

pastedImage_0.png

0 Likes

Hello,

From the trace snippet you shared i couldn't find the stall sent by the device. The snippet you shared just shows 0xc0000011 when IN transfer is requested. 0xc0000030 is when endpoint is stalled.

Please look if there is stall sent by the firmware (when SS_RESET event occurs) and share the snippet.

Regards,

Rashi

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

Please review the thread history. The thread is about why when xferdata failed, the status is 0xc0000011 instead of 0xc0000030. There is no 0xc0000030 at all, if 0xc0000030 is checked on failure, the endpoint won't be reset at all since it is the host that call inEndpoint.reset() when 0xc0000030 and if it is not 0xc0000030 then reset won't be sent .

0 Likes
WGT_4383351
Level 5
Level 5
First like received

The above trace showed that the failed xferdata indeed make the status 0xc0000011, not 0xc0000030. That is why the status after the failure will be 0xc0000011, not 0xc0000030, and checking for 0xc0000030 won't work.

0 Likes
WGT_4383351
Level 5
Level 5
First like received

If the recommended way to deal with SS_RESET is let the host check on xferdata failure whether status is 0xc0000011 or 0xc0000030 and reset the endpoint , then there is no problem. But the current recommendation is to check only 0xc0000030, not 0xc0000011, which at least doesn't work for the setup here.

This mean there is something that happens here that is not already covered by the recommendation.

0 Likes

Hello,

I understand that the error you are getting is 0xc000011.

But in your previous response as per my understanding you mentioned that this error (0xc0000011) is coming when the endpoint is stalled in the firmware (when ss reset is handled) instead of what is mentioned in the troubleshooting guide (0xc000030 i.e. endpoint stalled). So to confirm that i was asking for the traces to confirm that 0xc000011 is not due to firmware stall (ss reset event) but due to crc/pid errors (due to the link)

Now, as you are getting 0xc0000011 error and you have done endpoint reset in C# application you will get clear feature request which needs to be handled in the firmware by adding this to your 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 == 0x01)

                {

                    CyU3PDmaMultiChannelReset (&glDmaChHandle);

                    CyU3PUsbFlushEp(0x01);

                    CyU3PUsbResetEp (0x01);

                    CyU3PDmaMultiChannelSetXfer (&glDmaChHandle, CY_FX_GPIFTOUSB_DMA_TX_SIZE,0);

                    CyU3PUsbStall (wIndex, CyFalse, CyTrue);

                    isHandled = CyTrue;

                    CyU3PUsbAckSetup ();

                }

            }

        }

Let me know the results after this code is executed

Regards,

Rashi

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

When the xferdata fails, the facts are:

1. On the host side, xferdata fail, and state is 0xc0000011, and the C# code will reset the endpoint on this condition. This C# code is from the recommendation - when xferdata fail, check the status, if it is 0xc0000030 then reset the device. But if I check 0xc0000030 the device won't be reset since it is not 0xc0000030, it is 0xc0000011 that is received at that time. As a result checking for 0xc0000030 will render the device dead forever since no endpoint reset will ever by sent by the host.

2. On the device side, SS_RESET will be sent (as a workaround by the firmware, as described by the KB, when a design defact render the device dead on bad link condition), and the firmware that respond to SS_RESET will stall the device. This fact is what I called "STALLED".

Where ever 0xc0000011 come from, the point is that checking 0xc0000030 doesn't work at least or this setup.

0 Likes

Hello,

I understand your problem.

Now as you are getting 0xc0000011 error we need to handle the this error and do a work around

So, when you get this error, in C# application endpoint reset is sent which is equivalent to clear feature request and not the SS_RESET event.

So we need to handle this clear feature request in the firmware by adding the following code. This is handled in the following code

Please select the transfer where you are sending the endpoint reset URB_FUNCTION_SYNC_RESET_PIPE_AND_CLEAR_STALL (i.e. 1972 in the trace ) and take a snippet of that transfer so that  i can see the details of that transfer (wValue, bRequest  to be checked)

pastedImage_0.png

Regards,

Rashi

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

"

So, when you get this error, in C# application endpoint reset is sent which is equivalent to clear feature request and not the SS_RESET event.

So we need to handle this clear feature request in the firmware by adding the following code. This is handled in the following code

"

These are already in the firmware. The C# application here call inEndpoint.reset() when xferdata fail and at that tiem state is 0xc0000011, and the firmware respond to SS_RESET and STALL the device when SS_RESET, and the firmware also deSTALL the device when clear feature is received. All these are the recommendation, except for 0xc0000030 is replaced by 0xc0000011 on the C# program.

0 Likes
WGT_4383351
Level 5
Level 5
First like received

pastedImage_0.png

0 Likes
WGT_4383351
Level 5
Level 5
First like received

Make this question clear:

The recommendation doesn't work since 0xc0000030 is never received. It will work when 0xc0000030 is replaced by 0xc0000011 in the C# program.

What to do : find out the reason and update your KBA if needed. There is no support needed for us, since this only happen with bad cable, and we already find a work around - replace 0xc0000030 with 0xc0000011

0 Likes