FX3 bulk-in and control-in transfer confliction on USB 2.0

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

cross mob
frankchen
Level 3
Level 3
25 sign-ins 25 replies posted 10 replies posted

Hi,

I am working on a project which uses FX3 to implement video application. Basically the device works fine. But when it is connected to USB 2.0 port and run bulk-in (video data) and control-in (register read) simultaneously, both bulk-in and control-in will hang. If bulk-in and control-in are not run simultaneously, or they are run in USB 3.0, everything is fine.

My firmware SDK is ver 1.3.4

The problem is the same (or silimar) to those discussed in the following links:

1) a strange delay in USB2.0 

2) [CX3] uvc bulk-in transfer failed by control-out request on usb2.0  

3) FX3 highspeed control endpoint issue

Also I checked the following discussions:

1) CYUSB3014 - How to speed up operate control endpoint IN for USB highspeed 

2) EZ-USB® FX3™ Issues With Simultaneous Bulk-IN and Control-IN Transfers In USB 2.0 – KBA92475 

Refering to the solutions in above links, I made changes in FX3 firmware code by the two methods as follows:

1.  Use CyU3PUsbSetEpSuspDisableMask() to disable DMA channel suspend during EP0 transfer

or

2. Write another funcition CyU3PDmaChannelSendData() to replace CyU3PUsbSendEP0Data() for control-in data sending.

Both method is helpful on this issue. The bulk-in and control-in are not hang mostly.  But sometimes the data on control-in are corrupted. And sometimes the data transfer (both bulk-in and control-in) still failed (but not frequenctly and can be recoveried by end point reset).

The SDK ver 1.3.4 implements DMA suspend when control-in data needs to be sent out, to workaround data corruption issue in USB 2.0. But based on my issues (and other ones' issues in above links) it seems the DMA suspend operation is not stable. The above two method roll-backs the DMA suspend, but this does'nt resolve the data corruption issue.

I did the following test:

1. Remove control-in code, so there is only bulk-in transfer.

2. Added some code (the code is similar to those in ver 1.3.4 SDK CyU3PUsbSendEP0Data() function) which suspends bulk-in DMA, and then resume DMA after some delays (from some ms to some seconds). I can also see the bulk-in transfer may hang. So it looks the DMA suspend operation is not safe for us to call.

Here are the questions:

1. Why the DMA suspend/resume operation makes the transfer hang?

2. Is there any way to workaround the data corruption and hang issue for simultaneous bulk-in and control-in transfer in USB 2.0? That is, is there anyway to get stable bulk-in/control-in transfer for USB 2.0?

Thanks!

 

0 Likes
1 Solution

Hi Jayakrishna,

This is exactly the approach that I used now. I have tested in this way and I can get stable bulk and control transfers and never get any data errors. There is a small delay (about 10~15ms or even less) when control transfer happens, but this is acceptable for my application since the control transfer doesn't happen frequently.

Just one more thing, in step 2 and 3, after waiting for some time, I still use CyU3PUsbSendEP0Data() to initiate the control transfer so the DMA suspend operation may still be activated by the SDK internal code.

Thank you Jayakrishna and Rashi for all your helps!

Regards,

Frank

View solution in original post

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

Hello,

As you might already be aware of the reason of the issue, mentioned in point IV of section 2.3 of FX3 SDK trouble shooting guide, the issue (i.e. e data sent on the control endpoint gets corrupted) is seen due to the endpoint block on FX3 fetches data prematurely from the DMA channel.

To avoid this all BULK-IN DMA channels are suspended for a short duration while the EP0-IN transfer is being completed (in SDK 1.3.3 and above)

1. Why the DMA suspend/resume operation makes the transfer hang?

>> Suspending the DMA channel (for BULK transfer) will not allow the data transfers through BULK IN endpoint

 Is there any way to workaround the data corruption and hang issue for simultaneous bulk-in and control-in transfer in USB 2.0? That is, is there anyway to get stable bulk-in/control-in transfer for USB 2.0?

>> CyU3PUsbSetEpSuspDisableMask() API is provided by SDK to skip socket suspend when CyU3PUsbSendEP0Data() is called. But for this to be used it has to be taken care that Bulk transaction does not happen (while disable mask is ON).

Regards,
Rashi
0 Likes

Hi Rashi,

Thanks for your reply!

For the question 1 in my original post, I understand that suspending the bulk-in DMA channel will not allow the data transfers through bulk-in endpoint. But the DMA channel resume operation should allow the transfer to continue. However it looks like the suspend/resume operation implemented in SDK 1.3.4 CyU3PUsbSendEP0Data() function does not work as expected. Based on my issue (and other ones' issues in reference links) the bulk-in dma channel suspend/resume operation makes transfer hang and can not be resumed.

For your comment on question 2, it means that we need to stop/pause bulk-in transfer or synchronize bulk-in and control-in transfer in some way instead of the normal DMA suspend/resume method. For this method, could you please let me know is there any API that we can call to check if the DMA produce/consume DMA buffers are empty? This would be helpful for us to sync the bulk-in and control-in transfers.

Regards,

Frank

0 Likes

Hello Frank,

I understand that the other threads that you have pointed are referring to the delay caused in CONTROL IN transfers as all the BULK IN related DMA channels are suspended in CyU3PUsbSendEP0Data.

Please let us know more about your application and where is CyU3PUsbSendEP0Data is called in your application.

To avoid the delay on control endpoint (due to CyU3PUsbSendEP0Data), if we use CyU3PUsbSetEpSuspDisableMask() API is provided by SDK to skip socket suspend  (which should reduce the time to suspend the IN channels as Ep suspend is disabled) when CyU3PUsbSendEP0Data() is called, then to avoid the data corruption during premature fetching of data from DMA, we need to make sure that BULK IN transfers do not happen when disable mask is on

Could you please let me know is there any API that we can call to check if the DMA produce/consume DMA buffers are empty? This would be helpful for us to sync the bulk-in and control-in transfers.

>> This can be done from the application level from the host side i.e. if an Control IN is not complete, the BULK IN request should not be issued /issued after control in is completed. Please let us know more about your application to suggest a better solution

Regards,
Rashi
0 Likes

Hi Rashi,

Thanks for your help!

The main issuse that I have is the data trasnfer hang/stall issue but not the "delay" issue. I believe the issue I have is same  to those discussed in the threads that I referred.

As you know the "delay issue" is a side effect of the workaround which is implemented in SDK 1.3.4 (and perhaps other earlier or later versions). I verified that the "delay" can be removed by calling CyU3PUsbSetEpSuspDisableMask(). 

For me, a little delay (for eg., 10~50ms) during control-in event is acceptable. The problem is that, the workaround introduced in SDK 1.3.4 makes transfer hang/stall. And further test indicates that the DMA suspend operation will lead to transfer hang, and the transfer can not be recovered by resume operation, and both bulk-in and control-in channel are broken. This is not happen for every transfer, but it really happens after some video frames in my application.

So I have to disable the workaround by calling CyU3PUsbSetEpSuspDisableMask() or write another function to replace CyU3PUsbSendEP0Data(). But in this way I need to sync the bulk-in and control-in transfer in some way, such as the host side control method as you suggested. But this way makes the host side application complicated.

I prefer to fix this issue in FX3 firmware (and some delay is acceptable).

In my FX3 firmware, a thread is created to handle control-in requests. CyU3PUsbSendEP0Data() is called in this thread. So the bulk-in DMA suspend/resume are called in this thread too. Not sure if there is any limitation for the use of DMA suspend/resume operations.

Regards,

Frank

0 Likes

Hello Frank,

And further test indicates that the DMA suspend operation will lead to transfer hang, and the transfer can not be recovered by resume operation, and both bulk-in and control-in channel are broken

>> Please let me know if the issue "hang" is seen when the CyU3PUsbSetEpSuspDisableMask() is used

This is not happen for every transfer, but it really happens after some video frames in my application.

>> Please share the USB traces when the issue is seen. You can use Wireshark for the same Please do not use CyU3PUsbSetEpSuspDisableMask. For this test, we can just check how is SDK 1.3.4 causing the hang

CyU3PUsbSendEP0Data() is called in this thread. So the bulk-in DMA suspend/resume are called in this thread too. Not sure if there is any limitation for the use of DMA suspend/resume operations.

>> Is it possible to share the firmware snippet with these handling? 

Regards,
Rashi
0 Likes

Hi Rashi,

I have made progress on this issue, and even managed to get stable bulk-in and control-in transfers.

I did in the following way:

1、Do not call CyU3PUsbSetEpSuspDisableMask(),  and use CyU3PUsbSendEP0Data(). That is, the workaround instroduced in SDK 1.3.2 and later are enabled.

2、Before calling  CyU3PUsbSendEP0Data(), pause the data stream that is input to GPIF. After CyU3PUsbSendEP0Data() has finished, resume the data stream to GPIF.

In this way I can get stable video and control-in transfer.

Regarding your comments:

>> Please let me know if the issue "hang" is seen when the CyU3PUsbSetEpSuspDisableMask() is used

Yes, the "hang" issue is also seen when CyU3PUsbSetEpSuspDisableMask() is used. But it's quite different from the result when CyU3PUsbSetEpSuspDisableMask() not being used. When CyU3PUsbSetEpSuspDisableMask() is not used, the device will hang immediately after several video frames captured or even zero frame can be captured. When CyU3PUsbSetEpSuspDisableMask() is used it is much better and I can capture many frames. But the data transfered on control-in endpoint may be incorrect sometimes. And sometimes the bulk-in and/or control-in channel may still be broken - means that the end point can not transfer data any more unless I reboot the device.

>> Please share the USB traces when the issue is seen. You can use Wireshark for the same Please do not use CyU3PUsbSetEpSuspDisableMask. For this test, we can just check how is SDK 1.3.4 causing the hang

I'll capture and post the trace data tomorrow.

>> Is it possible to share the firmware snippet with these handling? 

My firmware is developed based on cyfxgpiftousb. The handling of control-in CY_U3P_USB_VENDOR_RQT event is very similar to those in CyFxApplnUSBSetupCB() function in cyfxgpiftousb example firmware. Since it also has company-private code, I am not able to post them now. Based on the progress that mentioned above, it looks like the issue is not related to the control-in handling. Perhaps it is related to the GPIF/DMA handling and/or suspend operations?

Anyway I am now able to get stable transfers. I'll try to capture some "hang" traces tomorrow for your reference.

Regards,

Frank

0 Likes

Hello Frank,

Thank you for the updates.

When CyU3PUsbSetEpSuspDisableMask() is not used, the device will hang immediately after several video frames captured or even zero frame can be captured.

>> Getting stuck at zero frame seems strange. Can you please try putting some debug prints in the thread entry function for loop and one after calling CyU3PUsbSendEP0Data and get the UART debug prints. This is to check where exactly is the firmware getting stuck or is it returning from CyU3PUsbSendEP0Data or not.

When CyU3PUsbSetEpSuspDisableMask() is used it is much better and I can capture many frames. But the data transferred on control-in endpoint may be incorrect sometimes

>> Incorrect data on control endpoint is expected when we have simultaneous bulk in and control in transfer without suspending the channel but hang after disabling the suspend seems strange.

The UART debug prints and USB traces can be helpful to check where is the program control stuck

Regards,
Rashi
0 Likes

Hi Rashi,

Thanks for your advice. I'll try to log the debug message. The uart port conflicts with other modules for my configuration. I'll try to find other ways to capture debug messages.

Regards,

Frank

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

Hi Rashi,

>> Please share the USB traces when the issue is seen. You can use Wireshark for the same Please do not use CyU3PUsbSetEpSuspDisableMask. For this test, we can just check how is SDK 1.3.4 causing the hang

Attached please find the Wireshark data traces. In this case CyU3PUsbSetEpSuspDisableMask() is not used. No video frame can be captured and control-in is broken after 17:35:30.309779

frankchen_1-1642758822678.png

It is expected to receive acknowledgement for vender request (No. 3178) but there is no response. 

Regards,

Frank

0 Likes

Hello Frank,

From the Wireshark traces, I could see that response to 3178 request is at 3261 (1s later) but this request is cancelled. 

Please let me know the timeout value of the control request on the host side. If possible, please try increasing the control in timeout.

Regards,
Rashi
0 Likes

Hi Rashi,

Thanks for help on this issue!

The host side timeout value is 200ms. Not sure why the actual timeout value is 1s. The host side timeout is set in the following way:

CCyControlEndPoint *ept = mUSBDevice->ControlEndPt;

.....

ept->TimeOut = 200;

 

Then I changed ept->TimeOut to 2000 (2s), the actual timeout is 2s. And when ept->TimeOut changed to 10000 (10s), the actual timeout is 10s. The response is always "cancelled" when timeout occured.

It seems that the FX3 DMA  does not work properly when the issue happenes. But not sure what is the root cause.

Regards,

Frank

0 Likes

Hello Frank,

Thank you for the update.

To debug the problem we would need to confirm if the firmware is stuck in CyU3PUsbSendEP0Data for the whole time when the issue is seen or is there a different problem. To check this, as suggested earlier, please try putting some debug prints.

I understand that you are using Cypress USBSuite  for creating host app. Is it possible for you to check the firmware with streamer (BULK IN) and control center (Control IN) in  USB 2.0 and see if the issue is reproducible with these app or does it happen only with the custom host app

Also, please let me know if you are plugging the device in USB 2.0 port/using USB 2.0 cable or configuring second parameter of CyU3PConnectStateAPI as CyFalse

Regards,
Rashi
0 Likes

Hi Rashi,

>>To debug the problem we would need to confirm if the firmware is stuck in CyU3PUsbSendEP0Data for the whole time when the issue is seen or is there a different problem. To check this, as suggested earlier, please try putting some debug prints.

I ported CDC driver to the firmware from the beginning of the FX3 firmware project, and I can get CyU3PDebugPrint() messages from host side COM port over the USB serial. But after many changes to the firmware, the CDC doesn't work now. I need some time to recovery CDC feature or find other ways to capture debug messages.

Normally the CDC feature is removed (by #ifdef conditional compilation) to avoid any pontential conflicts with video and/or other features. For now, all the tests were done with CDC feature removed.

>>I understand that you are using Cypress USBSuite  for creating host app. Is it possible for you to check the firmware with streamer (BULK IN) and control center (Control IN) in  USB 2.0 and see if the issue is reproducible with these app or does it happen only with the custom host app

I will check if we can do  in this way.

>>Also, please let me know if you are plugging the device in USB 2.0 port/using USB 2.0 cable or configuring second parameter of CyU3PConnectStateAPI as CyFalse

The device is connected to USB 3.0 port with USB 2.0 cable. The API is called in the following way:

CyU3PConnectState (CyTrue, CyTrue);

Regards,

Frank

0 Likes

Hello Frank, 

Thank you for the update

You can refer to this KBA  Adding Communication Device Class Interface to FX3... - Infineon Developer Community   for adding CDC interface to firmware

Regards,
Rashi
0 Likes

Hi Rashi,

Thanks for your info.

I have recovered the CDC feature successfully on my firmware, and can add/capture debug messages now.

Based on the debug message output, I can see the firmware is stuck in CyU3PUsbSendEP0Data().

I added debug messages in the following way:

CyU3PDebugPrint (4, "Before CyU3PUsbSendEP0Data()\r\n");
status = CyU3PUsbSendEP0Data(count, buffer);
CyU3PDebugPrint (4, "After CyU3PUsbSendEP0Data()\r\n");

The serial output are as follows:

...........

Before CyU3PUsbSendEP0Data()
After CyU3PUsbSendEP0Data()
Before CyU3PUsbSendEP0Data()
After CyU3PUsbSendEP0Data()
Before CyU3PUsbSendEP0Data()
After CyU3PUsbSendEP0Data()
Before CyU3PUsbSendEP0Data()
After CyU3PUsbSendEP0Data()
Before CyU3PUsbSendEP0Data()
After CyU3PUsbSendEP0Data()
Before CyU3PUsbSendEP0Data()
After CyU3PUsbSendEP0Data()
Before CyU3PUsbSendEP0Data()

In this case 3 video frames are captured sucessfully, and then I got device hang, which means no video can be captured any more and always got "canceled" error on control-in endpoint.

As mentioned before, there is no such issue if I pause the input data of GPIF before calling CyU3PUsbSendEP0Data().

Regards,

Frank

0 Likes

Hello Frank,

Please let us know if the input data of GPIF II is always committed when the CyU3PUsbSendEP0Data () is called or is the input data of GPIF II committed only when the firmware gets stuck?

From the shared logs, as you mentioned, it looks like the device gets stuck within the API CyU3PUsbSendEP0Data () when you are performing simultaneous CONTROL and IN transfers. Is the issue seen only on your custom application or is it also seen on Streamer + control center applications supplied by Infineon? Please test this and let us know the results.

Also, as you might be knowing from the previous posts, the workaround given in SDK 1.3.4 is to avoid the data corruption issue seen in USB 2.0 mode. To avoid this issue, simultaneous bulk IN and control transfers should be avoided. As you have a control to pause the input data of GPIF II, please let us know if this approach can be used as a workaround for this issue or not. If yes, then the following approach mentioned by Rashi in her previous reply can be used as a workaround for this issue:

"CyU3PUsbSetEpSuspDisableMask() API is provided by SDK to skip socket suspend when CyU3PUsbSendEP0Data() is called. But for this to be used it has to be taken care that Bulk transaction does not happen (while disable mask is ON)."

Please test this approach and let us know if you are still seeing the errors.

Best Regards,
Jayakrishna
0 Likes

Hi Jayakrishna,

Thanks for your reply.

>>Please let us know if the input data of GPIF II is always committed when the CyU3PUsbSendEP0Data () is called or is the input data of GPIF II committed only when the firmware gets stuck?

The input data of GPIF II comes from image sensor continuously. The input data of GPIF II is committed once it is received by FX3 DMA. So I think it is always committed no matter CyU3PUsbSendEP0Data() is being/not being called or something else.

>>From the shared logs, as you mentioned, it looks like the device gets stuck within the API CyU3PUsbSendEP0Data () when you are performing simultaneous CONTROL and IN transfers. Is the issue seen only on your custom application or is it also seen on Streamer + control center applications supplied by Infineon? Please test this and let us know the results.

The firmware is tested with our custom application. For now, I can't test the firmware with Streamer application becacause we need a serial of setup operations before we can get data from the device. However based on my tests I believe the problem is in firmware but not the application side.

>>Also, as you might be knowing from the previous posts, the workaround given in SDK 1.3.4 is to avoid the data corruption issue seen in USB 2.0 mode. To avoid this issue, simultaneous bulk IN and control transfers should be avoided. As you have a control to pause the input data of GPIF II, please let us know if this approach can be used as a workaround for this issue or not. If yes, then the following approach mentioned by Rashi in her previous reply can be used as a workaround for this issue:

Yes, for me this approach (pause the input data of GPIF) can be used as a workaround.

>>"CyU3PUsbSetEpSuspDisableMask() API is provided by SDK to skip socket suspend when CyU3PUsbSendEP0Data() is called. But for this to be used it has to be taken care that Bulk transaction does not happen (while disable mask is ON)."

>>Please test this approach and let us know if you are still seeing the errors.

I have tested this approach. It did make different results. By calling CyU3PUsbSetEpSuspDisableMask() I can get much more video frames, but I got data corruption on control-in channel sometimes and after some period the device may still stuck. But when I did this test I didn't ensure bulk and control in transaction not happenning simultaneously.

It looks that by pausing the input of GPIF before calling  CyU3PUsbSendEP0Data(), the DMA suspend operation in  CyU3PUsbSendEP0Data() can work properly.

Regards,

Frank

0 Likes

Hello Frank,

The key point here is to avoid bulk and control transfers from happening together. If you are able to pause the data input from GPIF II when control transfers are done, then it should avoid simultaneous control and bulk transfers. Also, please make sure that any DMA operations for sending the data received from GPIF II block are also completed when you call the CyU3PUsbSendEP0Data(). For this, you can make use of the CONS_EVENT notification for the corresponding DMA channel.

Best Regards,
Jayakrishna
0 Likes

Hi Jayakrishna,

Thanks.

Could you please provide more details or any example code on how to handle the CONS_EVENT notification to guarantee the corresponding DMA operations for sending data has completed? This should be helpful for me to avoid potential confliction issues. 

Regards,

Frank

0 Likes

Hello Frank,

We do not have an example project for this purpose as such. But you can refer to the following example project in the FX3 SDK:
C:\Program Files (x86)\Cypress\EZ-USB FX3 SDK\1.3\firmware\basic_examples\cyfxbulksrcsink

This project actually registers for a CONS_EVENT. The CONS_EVENT is received when the data is completely consumed by the consumer socket. Similarly PROD_EVENT is received when a DMA buffer is filled by the producer socket. So, if the number of PROD_EVENTs is greater than number of CONS_EVENTs received, then we can understand that we have few DMA buffers that are committed by FX3 but that still needs to be consumed by the consumer.

You can implement your own code to track the number of DMA buffers that are committed but not sent out through the consumer. When you initiate a control transfer, there should not be any such buffers left out. If such buffers exist, then it might still cause corruption of data in control endpoint or the hanging issue that you saw before.

Best Regards,
Jayakrishna
0 Likes

Hi Jayakrishna,

Thanks for your deteaild explanation!

I tested this approach.  In DMA callback function the CY_U3P_DMA_CB_PROD_EVENT notification is generated, but CY_U3P_DMA_CB_CONS_EVENT is never generated. 

Below are part of my firmware code:

uint32_t glDMARxCount = 0; /* Counter to track the number of buffers received. */
uint32_t glDMATxCount = 0; /* Counter to track the number of buffers transmitted. */

void DmaCallback (CyU3PDmaMultiChannel *chHandle, CyU3PDmaCbType_t type, CyU3PDmaCBInput_t *input)
{
    ......

    if (type == CY_U3P_DMA_CB_PROD_EVENT)
    {
        ......

        /* Increment the counter. */
        glDMARxCount++;
        CyU3PDebugPrint (4, "RxCount = %d\r\n", glDMARxCount);
    }

    if (type == CY_U3P_DMA_CB_CONS_EVENT)
    {
        ......

        /* Increment the counter. */
        glDMATxCount++;
        CyU3PDebugPrint (4, "TxCount = %d\r\n", glDMATxCount);
    }

    if (type == CY_U3P_DMA_CB_CONS_SUSP)
    {
    }
}

    ......

    dmaCfg.notification = CY_U3P_DMA_CB_CONS_EVENT | CY_U3P_DMA_CB_CONS_SUSP | CY_U3P_DMA_CB_PROD_EVENT;
    dmaCfg.cb = DmaCallback;
    apiRetStatus = CyU3PDmaMultiChannelCreate (&dmaMultiChHandle, CY_U3P_DMA_TYPE_AUTO_MANY_TO_ONE, &dmaCfg);

On PC host I can get video frames sucessfully, but only "RxCount" messages are printed out.

......

RxCount = 1
RxCount = 2
RxCount = 3
RxCount = 4
RxCount = 5
RxCount = 6
RxCount = 7
......

RxCount = 6991
RxCount = 6992
RxCount = 6993
RxCount = 6994

......

Did I miss something in the firmware code?

Regards,

Frank

0 Likes

Hello Frank,

Firstly, it is not recommended to use debug prints inside DMA callbacks as debug prints are blocking calls.

Second, please let me know if you are using AUTO channel. From your code snippet, I understand that you are using AUTO channel. The notifications and callbacks with events are supported only for MANUAL channel.

Best Regards,
Jayakrishna
0 Likes

Hi Jayakrishna,

>>Firstly, it is not recommended to use debug prints inside DMA callbacks as debug prints are blocking calls.

Thanks for reminder. I'll remove the debug messages.

>>Second, please let me know if you are using AUTO channel. From your code snippet, I understand that you are using AUTO channel. The notifications and callbacks with events are supported only for MANUAL channel.

Yes, I am using AUTO channel. It seems I can not check the consumer DMA buffer in case AUTO channel is used.

Regards,

Frank

0 Likes

Hello Frank,

Yes, you cannot obtain the CONS_EVENT for an AUTO channel. It is not recommended to use callback with notifications for AUTO channel. If you still want to use AUTO channel, then you can try the following approach when a control transfer needs to be done:

1. Pause the FPGA

2. Wait for some time. This is for the existing bulk transfers (if any) to be finished

3. Initiate the control transfer

Please try this and let us know if you face any issues.

Best Regards,
Jayakrishna
0 Likes

Hi Jayakrishna,

This is exactly the approach that I used now. I have tested in this way and I can get stable bulk and control transfers and never get any data errors. There is a small delay (about 10~15ms or even less) when control transfer happens, but this is acceptable for my application since the control transfer doesn't happen frequently.

Just one more thing, in step 2 and 3, after waiting for some time, I still use CyU3PUsbSendEP0Data() to initiate the control transfer so the DMA suspend operation may still be activated by the SDK internal code.

Thank you Jayakrishna and Rashi for all your helps!

Regards,

Frank

0 Likes

Hello Frank,

We are glad to hear that the issue is solved.

Best Regards,
Jayakrishna
0 Likes