FX3 does not send ERDY after previously responding with NRDY to IN request

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.
mialc_1106291
Level 4
Level 4
10 questions asked 50 sign-ins 50 replies posted

We've developed firmware for a Cypress FX3 that implements a single interface with 4 bulk endpoints. One of the endpoints is for commands, another for status, and the remaining two endpoints are for bulk data OUT and bulk data IN. The host application initiates a transfer by sending a command on OUT endpoint 1 and then reading a status response on IN endpoint 2. Bulk data (if part of the transaction) is then exchanged using OUT endpoint 3 and IN endpoint 4. Everything works as expected when the device enumerates as a USB 2.0 device. However, I'm having an issue with the status endpoint (IN endpoint 2) when in super speed mode.

The host side initiates a read of the status endpoint and then sends the command. The USB 3 packet analyzer (Ellisys USB Explorer EX350) shows that the device responds to the IN request with a NRDY packet. The command is then sent and received by the device, and by stepping through the firmware in the debugger I can see that the status response gets committed. However, the FX3 never responds with ERDY and per USB 3 specification, the host does not attempt to read the IN endpoint again.

I saw a couple of other posts about this that suggest that poor signal quality may be causing bus errors. I registered a callback for CYU3P_USBEP_SS_RESET_EVT but that event is never received.

If I re-arrange the order of operations on the PC side (send command and then issue status read) and put a delay between sending the command and then reading the status endpoint, the device does indeed respond with the expected status packet. However, this is because the device never entered a flow control state. It is unrealistic to expect the device to be able to deliver the data immediately each time the application asks for it. I see no way to avoid the device occasionally entering a flow control state where it needs to send ERDY after it previously sent NRDY. How do I get the device to place ERDY on the USB bus once data is committed to the endpoint?

 

1 Solution

Hello,

The disabled "PAUSE" button is limited from EzUSBSuite (SDK 1.3.4). Using EzUSBSuite from SDK 1.3.3 should solve the issue.

I tried taking a trace of BULK OUT transfer with burst as 1. FX3 sends ERDY

ERDY.PNG

What are the expected register values?

>> I wanted to check the status of the endpoint by checking a valid bit, flow control bit and other fields of register. If the endpoint is not valid, it wont respond to USB traffic

 

Regards,
Rashi

View solution in original post

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

Hello,

Please refer to this KBA  Simultaneous IN/OUT USB Transfers in EZ-USB® FX3™ ... - Infineon Developer Community  and confirm that the host application handles the data transfers as mentioned in the KBA

Also, to confirm if the data is committed successfully, can you please try checking through the UART debug prints instead of the JTAG debugger.

 

Regards,
Rashi
0 Likes

Hi Rashi,

The host side software opens handles for each of the endpoints and overlapped structures so that it can perform asynchronous read/write oprations. Reads and writes are initiated through calls to ReadFile and WriteFile with the OVERLAPPED structure for the appropriate endpoint passed. We then call WaitForMultipleObjects or WaitForSingleObject to determine when the operation has completed or timed out and later call GetOverlappedResult to determine the status of the transfer. We've been using the same PC side code with FX2 and AVR USB controllers for over 10 years now and haven't had any issues. ANd as I mentioned, this code along with the FX3 firmware works as expected with USB 2.0. The difference is that in USB 2.0 mode the host will keep issuing IN tokens until the transfer completes or until the read is cancelled by the host application. With USB 3.0 the host seems to follow the USB specification and won't issue another IN after it has received NRDY until the device sends an ERDY.

My expectation from reading the USB 3.2 specification is that the FX3 should issue ERDY after I commit the DMA buffer associated with the endpoint.

We don't presently have the UART hooked up in our application. I am presently using a Cypress Superspeeed Explorer Kit so it should be possible to connect the UART, but that's going to require some time.

Thanks,
Michael

0 Likes

Hi Rashi,

I modified the code in such a way that I can guarantee that the buffer is being committed:

if ( CY_U3P_SUCCESS == CyU3PDmaChannelGetBuffer(&dmachStsEndp, &dmabuf, CYU3P_NO_WAIT) ) {
rgbStsBuf[ibStsCount] = cbStsBuf;
cbStsBuf++;
CyU3PMemCopy(dmabuf.buffer, rgbStsBuf, cbStsBuf);
if ( CY_U3P_SUCCESS != CyU3PDmaChannelCommitBuffer(&dmachStsEndp, cbStsBuf, 0) ) {
while ( 1 );
}
}
else {
while ( 1 );
}

I know the DMA buffer commit happens because I can continue to run the application and on the packet analyzer I can see that command is still being accepted by the device. If it were stuck in the loop then it wouldn't be consuming the command and would be stuck in one of the infinite loops.

Is there any chance that Superspeed Explorer has engineering silicon on it that has errata that could be causing the lack of ERDY responses? I guess I will modify the software and firmware and try a different USB endpoint to see if that makes any difference.

 

Thanks,
Michael

0 Likes

Hi Rashi,

I found a way to work around the problem by calling CyU3PUsbSendErdy(endpaddrSts, 0) after CyU3PDmaChannelCommitBuffer(&dmachStsEndp, cbStsBuf, 0). Making this call after I process the start command seems sufficient and it wasn't necessary to add the call anywhere else that I commit the DMA buffer for that endpoint. Am I doing something wrong or is this a bug in the FX3 PHY or USB Stack?

I ran into similar issue on the DTO endpoint (bulk data transfer out from host to device, endpoint 3). This endpoint gets configured when the host sends a set configuration request but the DMA channel isn't created until the PC sends a command to perform a data transfer. When the command is received I create an auto channel with signal:

dmacfg.size = 16384
dmacfg.count = 2;
dmacfg.prodSckId = CY_U3P_UIB_SOCKET_PROD_3;
dmacfg.consSckId = CY_U3P_PIB_SOCKET_3;
dmacfg.prodAvailCount = 0;
dmacfg.prodHeader = 0;
dmacfg.prodFooter = 0;
dmacfg.consHeader = 0;
dmacfg.dmaMode = CY_U3P_DMA_MODE_BYTE;
dmacfg.notification = CY_U3P_DMA_CB_XFER_CPLT | CY_U3P_DMA_CB_CONS_EVENT;
dmacfg.cb = &DtoEndpointDmaCallback;
if (( CY_U3P_SUCCESS != CyU3PDmaChannelCreate(&dmachDtoEndp, CY_U3P_DMA_TYPE_AUTO_SIGNAL, &dmacfg) ) ||
( CY_U3P_SUCCESS != CyU3PDmaChannelSetXfer(&dmachDtoEndp, cbXfrTxMac) )) {
rgbStsBuf[ibStsErc] = sercInternal;
return;
}

Once the transfer completes the PC sends an end command on the CMD endpoint (endpoint 1), a status packet containing an error code and amount of bytes is created, and committed to the STS endpoint (endpoing 2). The DMA channel is then destroyed by executing the following code:

CyU3PDmaChannelDestroy(&dmachDtoEndp);
CyU3PUsbFlushEp(endpaddrDto);
CyU3PUsbResetEp(endpaddrDto);

In our application we first use this command to download 16 bytes to the FPGA logic to tell it what to do. We then use the same command again to perform a larger data transfer with the FPGA logic.

The 16 byte download always succeeds and the packet analyzer shows that when the data packet is sent to the DTO endpoint (endpoint 3) the ACK sent by the FX3 specifies 0 in the number of packets field, as expected, because it doesn't expect to receive anymore data since the auto channel completed the transfer. According to the USB 3.2 specification the endpoint is now in the flow control state and must respond with ERDY before the host will issue another OUT. When the PC side application goes to perform the next download the AUTO DMA channel is created again with a non-zero number of bytes specified to be transferred between the USB periperhal and GPIF II interface. However, my packet analyzer shows that the FX3 never sends ERDY and as a result, the host never issues the OUT on that endpoint and won't issue a new out on the endpoint until CLEAR_FEATURE ENDPOINT_HALT is sent, which we send after the transfer times out.

I found that I can work around this problem by making the following call immediately after CyU3PDmaChannelSetXfer(&dmachDtoEndp, cbXfrTxMac):
CyU3PUsbSendErdy(endpaddrDto, 0)

Why is this necessary if the FX3 PHY or USB stack is supposed to handle flow control automatically? Am I doing something wrong when I create or destroy the DMA channel for the endpoint?

In case you are wondering why I'm creating and destroying the DMA channel: it's because I have two different modules that need to perform data transfers. One is used for FPGA configuration and the other is used for bulk data transfer between the PC application and the FPGA logic. Both use the GPIF II interface but they use separate state machines and their code resides in different modules.

I appreciate any help / insight that you can provide.

Thanks,
Michael

0 Likes

Hello Michael,

From your response, I understand that the DMA channel is being created and then destroyed once the data transfers are completed. And you are expecting that the endpoint related to that particular DMA channel should send ERDY when not in use. Is my understanding correct?

If yes, as the DMA channel is destroyed and the endpoint is reset and flushed, the ERDY might not be sent by the device.

Please let me know why is the channel destroyed. Is it due to some memory issues? If the DMA channel needs to be reused you can reset the DMA channel instead of destroying and re creating it.

If you can reset the channel, following can be used

CyU3PUsbSetEpNak (CY_FX_EP, CyTrue);
CyU3PBusyWait (125);

CyU3PDmaChannelReset (&glChHandle);
CyU3PUsbFlushEp(CY_FX_EP);
CyU3PUsbResetEp (CY_FX_EP);
CyU3PUsbSetEpNak (CY_FX_EP, CyFalse);

Please let me know if this helps

Regards,
Rashi
0 Likes

Hi Rashi,

I'm describing two different scenarios where I'm having an issue with ERDY not being sent. The first scenario involves a bulk IN endpoint that has a manual OUT DMA channel attached to it with the CPU as the producer and the consumer as the UIB endpoint 2. This channel is created when the FX3 notifies the application firmware of a configuraiton event and remains in existence until notification of a disconnect or reset. This is what my first post was about and my expectation is that when the IN endpoint entered the flow control state due to the host requesting data that wasn't yet available, the FX3 should issue ERDY when I commit a buffer to the DMA channel attached to the . Since neither the USB endpoint or DMA was reset or reconfigured, the FX3 should be aware that the endpoint is in the flow control state when I commit the DMA buffer it should issue ERDY on the USB bus. However, it does not issue ERDY on the bus unless I explicitly call CyU3PUsbSendErdy after commiting the DMA buffer.

The second scenario is a different issue that also involves ERDY. Let me try to summarize that scenario into the steps taken:
0. FX3 is connected to PC
1. PC sets configuration 1
2. Firmware configures USB endpoints 1, 2, 3, and 4 via calls to CyU3PSetEpConfig.
3. Firmware creates a manual IN DMA channel for endpoint 1 (we call this the CMD endpoint) with producer = CY_U3P_UIB_SOCKET_PROD_1 and consumer = CY_U3P_CPU_SOCKET_CONS. The transfer size passed to CyU3PDmaChannelSetXfer is 0. A callback is registered for the producer event.
4. Firmare creates a manual OUT DMA channel for endpoint 2 (we call this the STS endpoint) with producer = CY_U3P_CPU_SOCKET_PROD and consumer = CY_U3P_UIB_SOCKET_CONS_2. The transfer size passed to CyU3PDmaChannelSetXfer is 0. A callback is registered for the consumer event.
5. Firmware is now in a loop where it takes different actions based on the current state. The state it is in has it waiting for an event that signals notification of the reception of a buffer via the CMD endpoint.
6. At some point later in time the PC application handles to all 4 USB endpoints.
7. PC sends a 64 byte or smaller command packet on CMD endpoint and initiates a read on the STS endpoint (this IN request results in NRDY because FX3 is not ready yet)
8. Firmware receives event notifying it that there is a data packet in the DMA buffer that came from endpoint 1 (CMD endpoint).
9. Firmware dispatches the command to the appropriate handler. Received command is to enable the FPGA data interface. The GPIF peripheral is initialized but no DMA is created.
10. Firmware commits 2 byte response to IN endpoint 2 (STS endpoint). This is where ERDY would need to be sent so the host will retry the IN request.
11. PC receives status response from STS endpoint
12. PC sends command packet (CMD = data transfer to FPGA) on CMD endpoint and initiates a read on STS endpoint
13. Firmware receives event notifying it that there is a data packet in the DMA buffer that came from endpoint 1 (CMD endpoint).
14. Firmware calls dispatch for the CMD, which creates an auto channel DMA with producer = CY_U3P_UIB_SOCKET_PROD_3 and consumer = CY_U3P_PIB_SOCKET_3. Notification is setup for both CY_U3P_DMA_CB_XFER_CPLT | CY_U3P_DMA_CB_CONS_EVENT to call a callback function.
15. Firmware commits 2 byte response to IN endpoint 2 (STS endpoint).
16. PC receives status response from STS endpoint
17. PC calls WriteFile on USB OUT endpoint 3 to send a 16 byte packet to the FPGA Logic
18. PC waits for data transfer to complete
19. FX3 DMA transfers 16 bytes to GPIF and then DtoEndpointDmaCallback is executed and signals an event to let firmware know transfer has completed
20. PC sends end transfer command on OUT endpoint 1 and initiates a read of IN endpoint 2 (STS)
21. Firmware receives end transfer command and executes the end handler, which destroys the auto DMA channel that was created between CY_U3P_UIB_SOCKET_PROD_3 and CY_U3P_PIB_SOCKET_3
22. Firmware commits status response including error code (no error) and transferred byte count (16 in this case) to IN endpoint 2 manual DMA
23. PC receives status response
24. PC sends command packet (CMD = data transfer to FPGA) on CMD endpoint and initiates a read on STS endpoint
25. Firmware receives event notifying it that there is a data packet in the DMA buffer that came from endpoint 1 (CMD endpoint).
26. Firmware calls dispatch for the CMD, which creates an auto channel DMA with producer = CY_U3P_UIB_SOCKET_PROD_3 and consumer = CY_U3P_PIB_SOCKET_3. Notification is setup for both CY_U3P_DMA_CB_XFER_CPLT | CY_U3P_DMA_CB_CONS_EVENT to call a callback function.
27. Firmware commits 2 byte response to IN endpoint 2 (STS endpoint).
28. PC receives status response from STS endpoint
29. PC calls WriteFile on USB OUT endpoint 3 to send a 50,000,000 byte packet to the FPGA Logic. THIS is when the PC should issue and OUT token but does not because the NumP field of the ACK response issued by the FX3 in response to the 16 byte packet sent on OUT endpoint 3 in step 17 contains 0 meaning that the PC side controller thinks that the endpoint is in the FLOW control state and will not issue OUT until the FX3 issues ERDY.
30. PC waits for data transfer to complete but times out after 30 seconds because FX3 does not send ERDY even though a DMA transfer was setup on OUT endpoint 3
31. PC sends command packet contain abort command
32. PC sends end command and initiates status read
33. Firmware receives abort command, destroys the DMA and performs any other cleanup (endpoint flush and reset)
34. Firmware receives end command and doesn't do anything but reset the state machine after generating a 6 byte reponse that includes the aborted transfer error code and the number of bytes that were successfully transfered (0 in this case)
35. Firmware commits status response to endpoint 2 DMA and waits for a new command
36. PC receives status response
37. PC issues CLEAR_FEATURE ENDPOINT_HALT on endpoint 3 (DOUT endpoint)
38. Firmware handles CLEAR_FEATUE ENDPOINT_HALT:
CyU3PUsbFlushEp(endpaddrDto);
CyU3PUsbResetEp(endpaddrDto);
CyU3PUsbStall(endpaddrDto, CyFalse, CyTrue)


So, to answer your question, no I do not expect ERDY to be sent when there is no active DMA buffer. However, if you read through steps 14 - 30 you will see why the USB host controller thinks the FX3 is in the flow control state and that I have committed a DMA buffer but the FX3 does not issue ERDY so the OUT token doesn't get issued by the host.

I can't leave the DMA channel for the DTO (OUT endpoint 3) or DTI (IN endpoint 4) in tact once a transfer has completed because the PC may send a command that requires a manual channel to perform the data transfer for either of those endpoints because the CPU needs to modify the byte stream.

Thanks,
Michael

0 Likes

Hello Michael,

Thank you for the details.

Please provide the complete USB trace for us to check. The device is expected to send ERDY once the data is available.

Also, please check the point 15 of Known Problems and Limitations of FX3 SDK 1.3.4 in FX3 SDK release notes and check if there are any CY_U3P_USB_EVENT_EP_UNDERRUN events

Regards,
Rashi
0 Likes

I added code to change the frequency of the blink rate of the onboard LED when the CY_U3P_USB_EVENT_EP_UNDERRUN event occurs but am not seeing any change. I did confirm the code works by temporarily adding it to the CY_U3P_USB_EVENT_SETCONF event.

In the case of IN endpoint 2 (STS endpoint) the endpoint is configured and the DMA is created in response to CY_U3P_USB_EVENT_SETCONF. The following code is executed to configure the endpoint and create the DMA:

#define endpaddrSts 0x82

epcfg.enable = CyTrue;
epcfg.epType = CY_U3P_USB_EP_BULK;
epcfg.streams = 0;
epcfg.pcktSize = 1024; // size for Super Speed, this is set based on the return value of CyU3PUsbGetSpeed()
epcfg.burstLen = 1;
epcfg.isoPkts = 0;
CyU3PSetEpConfig(endpaddrSts, &epcfg);

dmacfg.size = cbEndp;
dmacfg.count = 1; // there shouldn't be any advantage to increasing this
dmacfg.prodSckId = CY_U3P_CPU_SOCKET_PROD;
dmacfg.consSckId = CY_U3P_UIB_SOCKET_CONS_2;
dmacfg.prodAvailCount = 0;
dmacfg.prodHeader = 0;
dmacfg.prodFooter = 0;
dmacfg.consHeader = 0;
dmacfg.dmaMode = CY_U3P_DMA_MODE_BYTE;
dmacfg.notification = CY_U3P_DMA_CB_CONS_EVENT;
dmacfg.cb = &CmdStsEndpointDmaCallback;
CyU3PDmaChannelCreate(&dmachStsEndp, CY_U3P_DMA_TYPE_MANUAL_OUT, &dmacfg);
CyU3PDmaChannelSetXfer(&dmachStsEndp, 0);

If the host sends CLEAR_FEATURE ENDPOINT_HALT for this endpoint then the following code will be executed:
CyU3PDmaChannelReset(&dmachStsEndp);
CyU3PUsbFlushEp(endpaddrSts);
CyU3PUsbResetEp(endpaddrSts);
CyU3PDmaChannelSetXfer(&dmachStsEndp, 0);
CyU3PUsbStall(endpaddrSts, CyFalse, CyTrue);

When the application has a status packet to send in response to a host command it executes the following code:

if ( CY_U3P_SUCCESS == CyU3PDmaChannelGetBuffer(&dmachStsEndp, &dmabuf, CYU3P_NO_WAIT) ) {
rgbStsBuf[ibStsCount] = cbStsBuf;
cbStsBuf++;
CyU3PMemCopy(dmabuf.buffer, rgbStsBuf, cbStsBuf);
CyU3PDmaChannelCommitBuffer(&dmachStsEndp, cbStsBuf, 0);
cbStsBuf = 0;
}
else {
while ( 1 ); // never hit during testing
}

I don't think item 15 of the known issues applies to endpoint 2 because I do not reset the DMA channel except in the case of CLEAR_FEATURE ENDPOINT_HALT, but we also reset the endpoint and clear the stall.

I think item 15 could apply to endpoint 3 because I do destroy the DMA channel between transfers. However, I don't get the CY_U3P_USB_EVENT_EP_UNDERRUN event. If you want the USB trace for this endpoint you can download the USB trace with Ellisys USB Explorer 350 Analyzer software using sharing identifier "{8df413ca-5e88-4c55-9aeb-2b24c52bfcc0}"

 

https://ellisys.com/products/usbex350/download.php

Thus far I've found 2 ways to work around the endpoint 3 issue:
1. Configure the endpoint to have a burst size of 16 instead of burst size 1. In this case the ACK to the 16 byte out transaction contains a value of 15 in the number of packets field. Therefore, the endpoint does not enter flow control state.
2. Call CyU3PUsbSendErdy(endpaddrDto, 0) after creating the DMA channel and setting the XFER size. This will work even when the burst size is 1.

Thanks,
Michael

0 Likes

Hello Michael,

I am not able to access the USB traces from the link that you shared. Please attach the zipped folder with the post.

I don't think item 15 of the known issues applies to endpoint 2 because I do not reset the DMA channel except in the case of CLEAR_FEATURE ENDPOINT_HALT, but we also reset the endpoint and clear the stall.

>> Can you please confirm if the DMA channel reset sequence is as mentioned in point 15 of known issues.

Call CyU3PUsbSendErdy(endpaddrDto, 0) after creating the DMA channel and setting the XFER size. This will work even when the burst size is 1.

>> CyU3PUsbSendErdyfunction allows the firmware to generate an ERDY TP for a specified endpoint. Under normal operation, ERDY TPs are automatically generated by the FX3 device as and when required. This function is provided to support exceptional cases where the firmware application needs to generate a specific ERDY TP.

As in normal conditions ERDY is sent automatically, we need to check if we can modify the firmware to send ERDY without explicitly calling the API

Regards,
Rashi
0 Likes

Hi Rashi,

The traces total 1.87GB and are still 388MB after zipping them, which is too much to attach to this thread. I uploaded the zip file to OneDrive with the hope of being able to create a sharable link that anyone can access but it appears that my employer has disabled that option. The only way to share the file through OneDrive is by having the system share access through email. Can you please private message me your email address or provide me with another mechanism to send the traces? I tried splitting the zip file into multiple parts with 7-zip but it won't allow me to attach those files.

Yes, I am now using the DMA channel reset sequence that was mentioned in point 15 of the known issues. After making this change, it still doesn't respond to ERDY when expected.

Thanks,
Michael

0 Likes

Hello Michael,

The USB traces shared seems to be USB 2.0 traces instead of USB 3.0. Please re share USB 3.0 traces.
Also, please let me know if you are using USB hub to connect the device to host.

Regards,
Rashi
0 Likes

Hi Rashi,

I just opened the captures and both include USB 3.0 data flow. I don't see the Link Upstream / Link Downstream states that you are showing, but I assume that that's due to a difference in the view or grouping settings. I have show Link Commands disabled under my view settings. Bus States, Ordered Sets, Show Low Poewr States, and Show Rejected PM Transactions are enabled while Link Commands, Show Isocrhonous Timestamps, and Show Unrecognized Raw Data are disabled. I have grouping enabled with all items enabled.

I've tried both with and without a USB 3.0 hub between the FX3 and the host.

Thanks,
Michael

 

 

0 Likes

Hello Michael,

It's strange to see that in endpoint3_not_sending_erdy, the device doesn't enter the U0 state, and also I didn't see that the device sent NRDY for any transfer.

In endpoint3_not_sending_erdy, I didn't see endpoint 1 sending NRDY but endpoint 1 sends ERDY which is expected from endpoint 2. Please confirm that CyU3PUsbSendErdy is not called from the firmware.

I am still reviewing the traces and will get back to you on it

Regards,
Rashi
0 Likes

Hi Rashi,

When creating endpoint_2_not_sending_erdy.u31t I removed all calls to CyU3PUsbSendErdy. If expand the IN transaction at time 876.882 956 762 you will see that the FX3 sends the host an NRDY packet at timestamp 876.772 957 004, which puts endpoint 2 in the flow control state. At 876.882 965 450 the host sends a command packet to endpoint 1 and the FX3 acks with number of packets = 0, which puts endpoint 1 in flow control state. Both endpoint 1 and 2 are single buffered in the device, meaning that the FX3 will not issue ERDY for endpoint 1 until the firmware frees the DMA buffer. The FX3 issues ERDY at 876.883 016 212 after the firmware has released the buffer on endpoint 1. Shortly after that the firmware will have commited a packet to endpoint 2 buffer. However, you can see that at 877.396 091 858 (513 milliseconds later) the host has cancelled the operation and sent CLEAR_FEATURE ENDPOINT_HALT after it failed to read endpoint 2 before the timeout.

When creating endpoint_3_not_sending_erdy.u31t I have a call to CyU3PUsbSendErdy for endpoint 2 after endpoint 2 commits the DMA buffer but I don't have any calls to it for endpoint 3. Pleae look at the markers (Yellow box on the left side, place your mouse over it) in this trace , as I placed a description of what is taking place. At time 18.483 969 172 the device ACKs the 16 byte data packet that was send on endpoint 3 and the ack includes Number of Packets = 0. According to section 8.10.1 (Flow Control Conditions) of the USB 3.2 specification, this means that endpoint 3 is now in the flow control state and as a result, the host will not issue another OUT transaction until the FX3 sends ERDY on endpoint 3.

Thanks,
Michael

 

0 Likes

Hello Michael,

Please let me know if the issue is reproducible using CYUSB3KIT-003.

Also, please call CyU3PUsbLPMDisable before starting the data transfers and let me know if the issue is seen. You call this API in CY_U3P_USB_EVENT_SETCONF event handling.

Also, let me know if the issue is seen with multiple USB hosts.

Kindly confirm that you use the following sequence for destroying the channel

CyU3PUsbSetEpNak (CY_FX_EP, CyTrue);
CyU3PBusyWait (125);

CyU3PDmaChannelDestroy (&glChHandle);
CyU3PUsbFlushEp(CY_FX_EP);
CyU3PUsbResetEp (CY_FX_EP);
CyU3PUsbSetEpNak (CY_FX_EP, CyFalse);

Regards,
Rashi
0 Likes

Hi Rashi,

Yes, I'm using CYUSB3KIT-003 for development, as we have not received prototypes of our boards.

I added the CyU3PUsbLPMDisable call for CY_U3P_USB_EVENT_SETCONF. Unfortunately, this hasn't made any difference. If I remove the CyU3PUsbSendErdy call for endpoint 2 or endpoint 3 then the same issue persists.

I have confirmed that I am using the workaround you described everywhere that I reset or destroy a DMA channel.

Thanks,
Michael

0 Likes

Hello Michael,

Please help me by reading PROT_EPO_CS1 register when the issue is seen for endpoint 3.

Please refer to FX3 TRM for the register address. You can use CyU3PReadDeviceRegisters for reading a particular register. You can refer to USBBulkSrcSink to check how to use the API

Regards,
Rashi
0 Likes

Hi Rashi,

Sorry I had to work on a different project for a couple of days and didn't get back to this until now.

I added the following code to read the PROT_EPO_CS1 register:

uint32_t prot_epo_cs1[16];
CyU3PReadDeviceRegisters((uvint32_t*)0xE0033600, 16, prot_epo_cs1);

Please see the attached images for the result.

Is there a better debugging tool? The debugger built into the CYUSB3KIT-003 uses OpenOCD and is slow. Further, it does not allow me to pause execution. If I don't setup my breakpoints at the beginning of the debug session then they won't be enabled. Sometimes it's convenient to be able to pause execution and look at the call stack, as well as set new breakpoints. I don't know why the onboard debugger can't do this but I'm willing to spend money on a better solution. Please suggest something.

Thanks,
Michael

0 Likes

Hello,

Further, it does not allow me to pause execution. If I don't setup my breakpoints at the beginning of the debug session then they won't be enabled

>> This is a known issue. Please refer to a similar thread Solved: break does not work after upgrading to FX3 SDK 1.3... - Infineon Developer Community  

 From the attached snippet the register value doesn't seem to be as expected. You can also print the register values using UART debug prints.

I understand that endpoint 3 is not configured for the burst transfers. If yes, numP is expected to show number <= to the burst size supported by the endpoint in the companion descriptor.

We are trying to get a USB trace for OUT endpoint and burst size =1

Regards,
Rashi
0 Likes

Hey Rashi,

Thanks for the information. Do you know if the J-Link is a better debugger? I'm going to need to come up with a solution for when our prototypes come back, as they do not have the debugging circuitry that is built into

I've been reluctant to add the UART debug prints since those won't always be available on our boards because in some cases we will use the UART for another purpose.

The registers show the state after committing the DMA buffer for endpoint 3 at the time when the host is expecting to receive data from that endpoint. The trace is correct, as I intentionally set burst size to 1 because setting burst size to something > 1 masks the ERDY issue. The host application has requested more data from the driver but the host doesn't issue the out token because the endpoint is in flow control state thanks to numP being 0. 

What are the expected register values?

Thanks,
Michael

0 Likes

Hello,

The disabled "PAUSE" button is limited from EzUSBSuite (SDK 1.3.4). Using EzUSBSuite from SDK 1.3.3 should solve the issue.

I tried taking a trace of BULK OUT transfer with burst as 1. FX3 sends ERDY

ERDY.PNG

What are the expected register values?

>> I wanted to check the status of the endpoint by checking a valid bit, flow control bit and other fields of register. If the endpoint is not valid, it wont respond to USB traffic

 

Regards,
Rashi
0 Likes