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

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

cross mob
bbfe_4086196
Level 2
Level 2
5 sign-ins Welcome!

Hi, Cypress expert.

I got a issue on bulk-in conflict with control-out request on cx3.

my board is cyusb3064 with ov7251 sensor, i can stream video properly, but i can't set gain/exposure via e-CAM .

seems bulk-in can't working control-out/in at the same time. conflic with each other.

  • firmware startup, not streaming video, control-out ok (host send data via control type)
  • firmware startup, streaming video, open e-CAM's Options -> Video Capture Filter,  host ask device's gain GET_CUR_REQ

        device ack CyU3PUsbSendEP0Data() cause bulk-in failed (CyU3PDmaMultiChannelCommitBuffer Err = 0x47, size 10224)

  • set gain by e-CAM, device got control-out event, but can't got data by CyU3PUsbGetEP0Data sometimes, with error "USBStpCB:VCI Gain GetEP0Data = 0x49" , then host will send request after 5 seconds.  device can got data at that time.

i also try this  Knowledge Base Articles  EZ-USB® FX3™ Issues With Simultaneous Bulk-IN and Control-IN Transfers In USB 2.0 – KBA92475

but when i set bulk channel to suspend(CyU3PDmaMultiChannelSetSuspend,CyU3PDmaMultiChannelResume), the CyU3PUsbGetEP0Data didn't get return anymore. video on e-CAM lost, zero fps.

can you give me some suggestion to fix this issue, thanks.

0 Likes
1 Solution

Hello,

EDITED:

As per the traces shared in response 15 and 18, it seems that the device's response to the CONTROL IN requests is slow.

As I mentioned earlier, you can also try the workaround mentioned in this thread CYUSB3013 low control read performance with FX3 SDK library versions 1.3.2 and higher so that the performance of EP0 can be increased.

Please refer to this thread FX3: slow data rate from EP0 when DMA is active where the customer sees a similar problem.

Also, from the firmware shared, I see that CyU3PDebugPrint API is called in the DMA callback. Please do not call CyU3PDebugPrint API in the callbacks. You can either set events or use a global variable for tracking failures

Please confirm if that the streaming doesn't stop permanently with SKD 1.3.4.

Delay expected on the CONTROL IN endpoint as all channels are suspended before Control IN transfer. But the BULK endpoint is expected to work again. From the traces shared in response 18, the BULK IN transfers are working after the CONTROL IN transfer is done

As confirmed by you, that both bulk-in and control-in are working well i.e. without any data corruption under CyU3PUsbSetEpSuspDisableMask, But we do not recommend using this as this will lead to the problem mentioned in 4th point of section 2.3. FX3 troubleshooting guide.

Regards,

Rashi

Regards,
Rashi

View solution in original post

0 Likes
21 Replies
bbfe_4086196
Level 2
Level 2
5 sign-ins Welcome!

Hi, Cypress expert,

I got a workaround to fix this bug, but i want a correct solution to fix it.

1, CyU3PUsbGetEP0Data got 0x49/0x47 error, because e-CAM send 34 bytes commit string to device at stream on stage,

    but i just upload 26 byte for probe, i don't know why e-CAM give me 34 bytes. the last 8 bytes is random data.

2, CyU3PUsbSendEP0Data failed, i try to suspend bulk-in channel with CyU3PDmaMultiChannelSetSuspend,

     but after that i got CyU3PDmaMultiChannelCommitBuffer failed 0x47 error.

     so, i just set a flag when need send control-in, and discard video data in callback function.

     after contol-in data out, set flag back, continue commit video data to host.

This is not a reasonable way to fix this bug.

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

Hello,

Please let me know which SDK version are you using. Also, confirm the Build Variable (Project settings > C/C++ Build >Build variable). The Build variable should be 1_3_4 when using the latest SDK 1.3.4

Please refer to point 4 of section 2.3 FX3_SKD_troubleshooting guide in the SDK which mentions that workaround for this problem has been implemented in SDK versions 1.3.3 and later, where all BULK IN DMA channels are suspended for a short duration while the EP0 IN transfer is being completed. This is done within the USB driver in the SDK and no action is required on the application side.

Using the latest SDK https://www.cypress.com/documentation/software-and-drivers/ez-usb-fx3-software-development-kit  should solve this problem

If using the latest SDK (1.3.4) and the build variable is 1_3_4 then please share the UART debug prints and USB traces captured using Wireshark for us to check

Regards,

Rashi

Regards,
Rashi
0 Likes

Hi RashiV_61,

Thanks for supporting.

Please let me know which SDK version are you using

My build system is based on cygwin + arm-none-eabi-xx + sdk,  the sdk version is 1.3.4

This is done within the USB driver in the SDK and no action is required on the application side.

My host side is e-CAM,  you mean sdk has did bulk-in suspend during control-in transfer at verison 1.3.4 ?

don't need any mutex at application level .

I will try it following your direction , thanks.

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

Hi RashiV_61,

Upload wireshark and uart log for you.

log:

Set Commit 1

esSetCameraResolution 1

set high speed vga 30fps

get ov7255 id: 77 50

sensor id 77 50, status 1

ov7251 power up

sensor_set_auto_focus

UVC Started

cam strob irq

Gain ==> 81

send gain 64                                                                                          (open video capture filter in e-CAM)

CyU3PDmaMultiChannelCommitBuffer Err = 0x47, size 10224

CyFxUvcAppPibCallback cbType 4, cbArg 0x1006, 0 0 0 2 0 0 0 0 0    (video data commit failed)

Backflow detected...

CyFxUvcAppPibCallback cbType 4, cbArg 0x1006, 0 0 0 0 0 0 0 0 0

CyFxUvcAppPibCallback cbType 4, cbArg 0x1006, 0 0 0 0 0 0 0 0 0

CyFxUvcAppPibCallback cbType 4, cbArg 0x1005, 0 0 0 0 0 0 0 0 0

CyFxUvcAppPibCallback cbType 4, cbArg 0x1005, 0 0 0 0 0 0 0 0 0

CyFxUvcAppPibCallback cbType 4, cbArg 0x1005, 0 0 0 0 0 0 0 0 0

CyFxUvcAppPibCallback cbType 4, cbArg 0x1005, 0 0 0 0 0 0 0 0 0

CyFxUvcAppPibCallback cbType 4, cbArg 0x1005, 0 0 0 0 0 0 0 0 0

Gain ==> 81

CyFxUvcAppPibCallback cbType 4, cbArg 0x1005, 0 0 0 0 0 0 0 0 0

send gain 64

CyFxUvcAppPibCallback cbType 4, cbArg 0x1005, 0 0 0 0 0 0 0 0 0

GpifCB:WrapUp SCK1 Err = 0x47

Gain ==> 81

send gain 64

stop here 4

ov7251 power down

UVC Stopped

esSetCameraResolution 1

set high speed vga 30fps

get ov7255 id: 77 50

sensor id 77 50, status 1

ov7251 power up

sensor_set_auto_focus

UVC Started

wireshark:

wireshark.png

0 Likes

Hi RashiV_61,

I checked "EZ-USB FX3 SDK\1.3\firmware\fx3_sdk_1_3_4_src\sdk\firmware\src\dma\cyu3multichannel.c",

can't find the code to avoid bulk-in and control-in , can you give some point about this.

static void

CyU3PDmaMultiChannelSetXfer_TypeManyToOne (

        CyU3PDmaMultiChannel *handle,

        uint32_t count,

        uint16_t multiSckOffset)

{

    CyU3PDmaSocketConfig_t sck;

    CyU3PDmaDescriptor_t dscr;

    uint16_t sckCount, index;

    /* Update the status information first. */

    handle->state = CY_U3P_DMA_ACTIVE;

    /* Disable the sockets */

    for (sckCount = 0; sckCount < handle->validSckCount; sckCount++)

    {

        CyU3PDmaSocketDisable (handle->prodSckId[sckCount]);

    }

    CyU3PDmaSocketDisable (handle->consSckId[0]);

   /* Set the consumer socket suspend option. */

    CyU3PDmaUpdateSocketSuspendOption (handle->consSckId[0],

            handle->consSusp);

    /* Update the producer reference pointers. */

    handle->currentProdIndex = handle->commitProdIndex =

        handle->firstProdIndex[multiSckOffset];

thanks.

0 Likes

Hello,

Please refer to the source of  CyU3PUsbSendEP0Data API which suspends all other IN endpoint channels when EP0 - IN transfer is going on

Please comment out the implementation that was added referring to EZ-USB® FX3™ Issues With Simultaneous Bulk-IN and Control-IN Transfers In USB 2.0 – KBA92475  this KBA as it is already implemented in the SDK 1.3.4.

Please let me know if the Wireshark traces provided is with the workaround implementation in the firmware or without it

Also, after removing the workaround, please let me know if the issue happens with Windows PC also. If yes, please share the Wireshark traces for that also.

Please confirm that CyU3PDebugPrints are not used in the DMA callback or any other callback functions

Regards,

Rashi

Regards,
Rashi
0 Likes

Hi RashiV_61,

Thanks for replying.

this wireshark.7z based on following context

Please comment out the implementation that was added referring to EZ-USB® FX3™ Issues With Simultaneous Bulk-IN and Control-IN Transfers In USB 2.0 – KBA92475  this KBA as it is already implemented in the SDK 1.3.4.

Yes, remove the CyU3PDmaMultiChannelSetSuspend(), CyU3PDmaMultiChannelResume().

Please refer to the source of  CyU3PUsbSendEP0Data API which suspends all other IN endpoint channels when EP0 - IN transfer is going on

from the code of cyu3usb.c, i found

   /* Suspend other channels to handle a USB EP0-IN transfer. */

    if (glUibDeviceInfo.usbSpeed != CY_U3P_SUPER_SPEED)

        CyU3PUsbSuspendInEpChannels ();

and

   /* Restore EPx-IN channels to their original state. */

    if (glUibDeviceInfo.usbSpeed != CY_U3P_SUPER_SPEED)

        CyU3PUsbResumeInEpChannels ();

so, i think i was use the right sdk 1.3.4 version.

Please let me know if the Wireshark traces provided is with the workaround implementation in the firmware or without it

Also, after removing the workaround, please let me know if the issue happens with Windows PC also. If yes, please share the Wireshark traces for that also.

Yes, after remove the workaround, the issue is still exist. from the wireshrk.7z trace, you can find bellow

the first cur gain request from host

1_gain_req.png

device ack cur gain

1_gain_ack.png

from the red line, you can see this, CyU3PUsbSendEP0Data break down the video data, host get unknown type 81 status.

after that, device restart streaming by timer reset.

same to next second/third gain request/ack

3_gain_ack.png

Please confirm that CyU3PDebugPrints are not used in the DMA callback or any other callback functions

Yes, all the log from dma/usb setup/event callback was removed.

I add a flag in dma callback, to check CY_U3P_DMA_CB_CONS_SUSP, after calling CyU3PUsbSendEP0Data, i found this flag was set in callback, so CyU3PUsbSuspendInEpChannels () is working.

I don't know why control-in break down bulk-in. what should i do next,

thanks .

0 Likes

RashiV_61

I test another device (uvc device from market) with e-CAM, capture wireshark traces, it's also has "Unknown type 81 Status" , but it's has some difference with us.

other.png

  1. control out/in very fast in 22us, cx3 need > 30ms after streaming.
  2. don't break down video transfer.

so, Unknown type 81 status is not the problem.

0 Likes

Hello,

From the Wireshark traces, I found that after the Control  IN transfers the video data is still seen o the bus i.e. the video data has not stopped completely.

- Please let me know if some video frames are seen on eCamView after Control IN transfer is done. Also, confirm that streaming never hangs when the control transfers are not done while streaming.

From the traces, it seems that the CONTROL IN transfers is not sent as the UVC SET/GET requests.

- Is it possible for you to try to control some other features of the video instead of the gain (for example brightness)? This is to check if the problem occurs with only this control or is it common to all the UVC requests.

- Can you share the firmware where the handling of this is being done (you can remove the sensor configuration settings) for us to check

- Just to confirm that the problem doesn't occur due to the host application, please try streaming using the MPC-HC host application https://mpc-hc.org/  on Windows PC and try to set the gain value. Please share the Wireshark traces for this test.

- If the only problem is Commit buffer failures seen when the Control IN transfers are done. Please refer to this KBA which mentions the reason for commit buffer failures Invalid Sequence Error in Multi-Channel Commit Buffer - KBA218830​ If the problem is only the commit buffer failures, this can be recovered by increasing the DMA buffer size and similarly changing the Rx payload field of the probe control structure. Please let me know the current DMA buffer size being used in the firmware.

Regards,

Rashi

Regards,
Rashi
0 Likes

Hi RashiV_61,

From the Wireshark traces, I found that after the Control  IN transfers the video data is still seen o the bus i.e. the video data has not stopped completely.

The video data after control-in is stopped.  after 400ms , reset timer handler restart streaming (stream stop/start).

the bulk-in video data should be on the bus by other ep-in resume in CyU3PUsbSendEP0Data.

q1.png

- Please let me know if some video frames are seen on eCamView after Control IN transfer is done. Also, confirm that streaming never hangs when the control transfers are not done while streaming.

If I remove the reset timer , after control-in ,e-CAM just show last view, streaming is hang.

From the traces, it seems that the CONTROL IN transfers is not sent as the UVC SET/GET requests.

- Is it possible for you to try to control some other features of the video instead of the gain (for example brightness)? This is to check if the problem occurs with only this control or is it common to all the UVC requests.

This is UVC SET/GET requests, just wireshark dont't parse totally, i tried brightness, it's the same problem.

- Can you share the firmware where the handling of this is being done (you can remove the sensor configuration settings) for us to check

Okay, handle gain

if((wIndex == 0x200) && (wValue == 0x400)) /*Gain*/

{          

//CyU3PDebugPrint (4, "Gain ==> %x\r\n", bRequest);

switch(bRequest)

{

case ES_UVC_USB_GET_INFO_REQ:

glGet_Info=0x03;

status = CyU3PUsbSendEP0Data(1,&glGet_Info);

if (status != CY_U3P_SUCCESS)

{

CyU3PDebugPrint (4, "USBStpCB:VCI SendEP0Data = %x\r\n", status);

}

break;

case ES_UVC_USB_GET_MIN_REQ:

case ES_UVC_USB_GET_MAX_REQ:

case ES_UVC_USB_GET_RES_REQ:

case ES_UVC_USB_GET_CUR_REQ:

case ES_UVC_USB_GET_DEF_REQ:

//RequestOption = (bRequest & 0x0F);

if (bRequest == ES_UVC_USB_GET_MIN_REQ)

gl16GetControl = 16;

else if (bRequest == ES_UVC_USB_GET_MAX_REQ)

gl16GetControl = 255;

else if (bRequest == ES_UVC_USB_GET_RES_REQ)

gl16GetControl = 1;

else if (bRequest == ES_UVC_USB_GET_DEF_REQ)

gl16GetControl = 64;

else if (bRequest == ES_UVC_USB_GET_CUR_REQ)

gl16GetControl = g_gain;

//CyU3PDebugPrint(4, "send gain %d\r\n", gl16GetControl);

status = CyU3PUsbSendEP0Data(2, (uint8_t*)&gl16GetControl);

if (status != CY_U3P_SUCCESS)

{

CyU3PDebugPrint (4, "USBStpCB:VCI Gain SendEP0Data = %x\r\n", status);

}

break;

case ES_UVC_USB_SET_CUR_REQ:

status = CyU3PUsbGetEP0Data(64,buf,&readCount);

if (status != CY_U3P_SUCCESS)

{

CyU3PDebugPrint (4, "USBStpCB:VCI Gain GetEP0Data = %x, cnt %d\r\n", status,

readCount);

}

if(readCount >= 2) {

gl16GetControl = (buf[1] << 😎 | buf[0];

g_gain = gl16GetControl & 0xffff;

}

break;

}

}

dma callback, i insert one line to include some information for host, like runtime gain, exposure time, timestamp, etc.

one frame is 640*481*2 bytes

void

esUVCUvcAppDmaCallback (

CyU3PDmaMultiChannel   *chHandle,

CyU3PDmaCbType_t  type,

CyU3PDmaCBInput_t *input

)

{

CyU3PDmaBuffer_t DmaBuffer;

CyU3PReturnStatus_t status = CY_U3P_SUCCESS;

if (type == CY_U3P_DMA_CB_PROD_EVENT)

{

#ifdef RESET_TIMER_ENABLE

CyU3PTimerStart (&uvc_timer);

g_timer1++;

#endif

status = CyU3PDmaMultiChannelGetBuffer(chHandle, &DmaBuffer,

CYU3P_NO_WAIT);

while (status == CY_U3P_SUCCESS)

{

/* Add Headers*/

if(DmaBuffer.count < ES_UVC_DATA_BUF_SIZE)

{

esUVCUvcAddHeader ((DmaBuffer.buffer -

ES_UVC_PROD_HEADER), ES_UVC_HEADER_EOF);

hit_fv = CyTrue;

#ifdef DEBUG_PRINT_FRAME_COUNT

frame_cnt++;

dma_done_cnt = 0;

#endif

g_dmabuf_count1 += DmaBuffer.count;

// CyU3PDebugPrint (4,"fps bytes %d\r\n", g_dmabuf_count1);

g_dmabuf_count1 = 0;

fill_extra_line(DmaBuffer.buffer+DmaBuffer.count);

}

else

{

esUVCUvcAddHeader ((DmaBuffer.buffer -

ES_UVC_PROD_HEADER), ES_UVC_HEADER_FRAME);

g_dmabuf_count1 += DmaBuffer.count;

}

/* Commit Buffer to USB*/

/*if (bulk_sleep) {

status = CyU3PDmaMultiChannelDiscardBuffer(chHandle);

} else {*/

if (hit_fv)

#if OV7251_RAW8

status = CyU3PDmaMultiChannelCommitBuffer (chHandle,

(DmaBuffer.count + 12 + 1280), 0);

#else

status = CyU3PDmaMultiChannelCommitBuffer (chHandle,

(DmaBuffer.count + 12 + 1600), 0);

#endif

else

status = CyU3PDmaMultiChannelCommitBuffer (chHandle,

(DmaBuffer.count + 12), 0);

//}

if (status != CY_U3P_SUCCESS) {

#if 0

CyU3PMipicsiErrorCounts_t err;

CyU3PMipicsiGetErrors(CyFalse, &err);

CyU3PDebugPrint (4, "err frmErrCnt %d\r\n crcErrCnt %d\r\n mdlErrCnt %d\r\n ctlErrCnt %d\r\n eidErrCnt %d\r\n recrErrCnt %d\r\n unrcErrCnt %d\r\n recSyncErrCnt %d\r\n unrSyncErrCnt %d\r\n",

err.frmErrCnt,

err.crcErrCnt, err.mdlErrCnt,

err.ctlErrCnt, err.eidErrCnt,

err.recrErrCnt, err.unrcErrCnt,

err.recSyncErrCnt, err.unrSyncErrCnt);

#endif

//CyU3PDebugPrint (4,

// "CyU3PDmaMultiChannelCommitBuffer Err = 0x%x, size %d\r\n", status,

// DmaBuffer.count);

CyU3PDmaMultiChannelAbort(chHandle);

CyU3PEventSet(&main_event, ES_TIMER_RESET_EVENT,CYU3P_EVENT_OR);

break;

}

else

{

dma_tx_cnt++;

dma_done++;

#ifdef DEBUG_PRINT_FRAME_COUNT

dma_done_cnt++;

#endif

}

active_socket ^= 1; /* Toggle the Active Socket */

status = CyU3PDmaMultiChannelGetBuffer(chHandle,

&DmaBuffer, CYU3P_NO_WAIT);

}

}

.......

buffer

#define ES_UVC_HS_DATA_BUF_SIZE (0x27f0)

#define ES_UVC_HS_STREAM_BUF_COUNT (9)

uint8_t const glVga30ProbeCtrl[ES_UVC_MAX_PROBE_SETTING] = {

0x00, 0x00,            /* bmHint : No fixed parameters */

0x01,                  /* Use 1st Video format index */

0x01,                  /* Use 2nd Video frame index */

0x15, 0x16, 0x05, 0x00,

0x00, 0x00, /* Key frame rate in key frame/video frame units */

0x00, 0x00,     /* PFrame rate in PFrame / key frame units */

0x00, 0x00,     /* Compression quality control */

0x00, 0x00,     /* Window size for average bit rate */

0x00, 0x00,     /* Internal video streaming i/f latency in ms */

#if OV7251_RAW8

0x00, 0x65, 0x09, 0x00,

#else

0x40, 0xbe, 0x0b, 0x00,

#endif

0x00, 0x90, 0x00, 0x00,

0x80, 0xd1, 0xf0, 0x08,

0x00, 0x00, 0x00, 0x00

/* No. of bytes device can rx in single payload: 36KB */

};

if you need any other information, please let me know.

Just to confirm that the problem doesn't occur due to the host application, please try streaming using the MPC-HC host application https://mpc-hc.org/  on Windows PC and try to set the gain value. Please share the Wireshark traces for this test.

Okay, i will try it later, then update result.

If the only problem is Commit buffer failures seen when the Control IN transfers are done. Please refer to this KBA which mentions the reason for commit buffer failures Invalid Sequence Error in Multi-Channel Commit Buffer - KBA218830. If the problem is only the commit buffer failures, this can be recovered by increasing the DMA buffer size and similarly changing the Rx payload field of the probe control structure. Please let me know the current DMA buffer size being used in the firmware.

I tried to enlarge ES_UVC_HS_STREAM_BUF_COUNT from 3 to 9, also increase ES_UVC_HS_DATA_BUF_SIZE from  0x27f0 to 0x5ff0, but the issue is still there.

I want know, for CONTROL-Get operation, the normal duration is in 10ms or 100us?

Can you give me a correct wireshark traces which CONTROL-in not conflict with bulk-in.

I can compare the trace flow, figure out the difference between us.

thanks for help.

0 Likes

Hi RashiV_61

- Just to confirm that the problem doesn't occur due to the host application, please try streaming using the MPC-HC host application https://mpc-hc.org/  on Windows PC and try to set the gain value. Please share the Wireshark traces for this test.

I tried mpc-hc player, have the same problem.

mpc-hc.png

mpc-hc1.png

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

Hello,

We have tried to reproduce the issue at our end when the device is connected as a USB 2.0 device but we do not see any error while doing Control IN/OUT transfers while streaming through AmCap (host application). Please find the attached results.

We see that SET/GET requests are being sent for UVC control requests unlike in your cake where CONTROL IN transfer is not interpreted as SET/GET request.

- Please confirm if in the descriptors the UVC control (gain in your case) is enabled. It seems that the issue is in the way the requests are being handled in the firmware.

- If possible please share the complete project for us to check the USB descriptor file, uvc.c file and the

- Also, confirm if the firmware is generated from the CX3 MIPI configuration tool as mentioned in this KBA Steps to Setup up MIPI CSI Camera Solution with CX3 – KBA225748

- Please let me know on which PC (PC configuration) are you currently trying to stream the video.

Regards,

Rashi

Regards,
Rashi
0 Likes

Hi RashiV_61

We see that SET/GET requests are being sent for UVC control requests unlike in your cake where CONTROL IN transfer is not interpreted as SET/GET request.

I found the step to make ‘SET/GET requests are being sent for UVC control requests'

1, start wireshark first

2, insert usb cable to pc

if not, such as don't plug out/in usb cable, just restart cx3 through command, then wireshark cann't decode packet by uvc protocol.

from the wireshark log, you can see bulk-in was break down for 871ms.

gain.png

- Please confirm if in the descriptors the UVC control (gain in your case) is enabled. It seems that the issue is in the way the requests are being handled in the firmware.

yes, the gain is enabled in uvc control descriptors. i'm not sure the way to handle gain request is correct.

can you share me your project , so i can porting my sensor configuration to your project step by step,

then find the rootcause.

- Please let me know on which PC (PC configuration) are you currently trying to stream the video.

My Pc's configuration

processor: Intel(R) Core(TM) i7-7700HQ CPU @ 2.8GHz

memory: 8GB

type: x64

windows version: windows 10 home

Thanks.

0 Likes

Hello,

can you share me your project , so i can porting my sensor configuration to your project step by step, then find the root cause?

>> AN75779 firmware https://www.cypress.com/documentation/application-notes/an75779-how-implement-image-sensor-interface...  handles the control request to control brightness in the firmware. You can refer to this Firmware and try to implement the same in your firmware for handling the requests.

Please note that the AN75779 firmware is for the FX3 device but the handling of the control requests will be implemented as in the firmware.

Please let me know if any queries on this.

Regards,

Rashi

Regards,
Rashi
0 Likes

Hi RashiV_61,

I compared AN75779, didn't find much more difference in control handler and descriptors.

I found some difference between your test and mine.

your bulk-in packets duration is form 300us to 5ms , but my case is almost 300us.

i add a timestamp print for CyU3PUsbSendEP0Data , as below

int64_val tss,tse;

get_ts_64(tss.m_bytes);

status = CyU3PUsbSendEP0Data(2, (uint8_t*)&gl16GetControl);

get_ts_64(tse.m_bytes);

CyU3PDebugPrint(4, "send gain %d, delta %d\r\n", gl16GetControl, tse.m_int64 - tss.m_int64);

got following uart traces

.....

AppInit:stream bufsize = 0x2800, data bufsize = 0x27F0, stream bufcnt = 0x2

send gain 16, delta 31942

send gain 255, delta 31987

send gain 1, delta 31974

send gain 16, delta 31984

set phy delay ok

.....

UVC Started

CyU3PDmaMultiChannelCommitBuffer Err = 0x47, size 10224 51120

send gain 70, delta 57435

stop here 4

send gain 70, delta 32030

send gain 70, delta 32029

ov7251 power down

.....

from the log, the first gain control get_def/min/max/res request , cost no more than 32ms,

but after video streaming, the first gain control get_cur cost 57ms.

from the wireshark traces.

111.png

Maybe my bulk-in packets is so frequently, cause next bulk-in commit failed.

actually, i can't setup enough memory to buffer these video data.

as their duration is to short.

whether this is a start point to debug? if yes, can you give some point to increase bulk-in duration.

Thanks.

0 Likes

Hi RashiV_61

Finally,  this bug be fixed by add CyU3PUsbSetEpSuspDisableMask(0xffff) after CyU3PUsbStart().

I don't know if this is a side effect of CyU3PUsbSendEP0Data changed on sdk 1.3.4, original problem is control-in affected by bulk-in transfer. so, add other ep-in suspend when control-in, but under my case, this is cause bulk-in failed.

Thanks

Best regards.

0 Likes

Hello,

Thank you for the update.

Please confirm that the data of the EP0 endpoint is not corrupted when simultaneous BULK IN transfer is done after the CyU3PUsbSetEpSuspDisableMask is being called in the firmware.

To avoid FX3 fetching data prematurely from the DMA channel we can try one more workaround. As BULK IN DMA channels are suspended, in SDK 1.3.4, for a short duration while the EP0 IN transfer is being completed. This is the reason for the lower performance of the EP0 endpoint as it suspends all other IN channels every time CyU3PUsbSendEP0Data API is called.

You can also try the workaround mentioned in this thread CYUSB3013 low control read performance with FX3 SDK library versions 1.3.2 and higher so that the performance of EP0 can be increased.

Please comment out the CyU3PUsbSetEpSuspDisableMask API and try the workaround mentioned in the above thread and let me know if this helps

Regards,

Rashi

Regards,
Rashi
0 Likes

Hi RashiV_61,

Please confirm that the data of the EP0 endpoint is not corrupted when simultaneous BULK IN transfer is done after the CyU3PUsbSetEpSuspDisableMask is being called in the firmware.

Yes, both bulk-in and control-in are working well under CyU3PUsbSetEpSuspDisableMask.

my firmware is created five devices, one uvc, one uac, two hid, one vcom. i don't know whether this is the difference from your end.

I tested just one uvc device (create clean project), bulk-in transfer failed is become occasionally, five times of gain control will success 2 or 3.

You can also try the workaround mentioned in this thread CYUSB3013 low control read performance with FX3 SDK library versions 1.3.2 and higher so that the performance of EP0 can be increased.

I checked with wireshark traces, the control-in performance is not low. you can refer to below picture.

new.png

Please comment out the CyU3PUsbSetEpSuspDisableMask API and try the workaround mentioned in the above thread and let me know if this helps

Based on above information, the control read performance is not low.  should i still need to try this workaround ?

Thanks.

Regards.

0 Likes

Hello,

Apologies for the late reply

I tested just one uvc device (create clean project), bulk-in transfer failed is become occasionally, five times of gain control will success 2 or 3

>> Please let me know if only with one UVC interface the problem is still seen.

Can you please let me know the steps you follow while testing the above? Can you share the firmware for us to check?

Regards,

Rashi

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

Please let me know if only with one UVC interface the problem is still seen.

Yes, the project just exposure uvc interface.

Can you please let me know the steps you follow while testing the above?

The test steps is no difference from whole project(2hid/vcom/uac/uvc)

1, insert to windows 10

2, open eCAM

3, start streaming

4, menu -> options -> video capture feature -> setting gain

Can you share the firmware for us to check?

As company policy, I can't share the full code for you. just post part code related to uvc/cx3.

0 Likes

Hello,

EDITED:

As per the traces shared in response 15 and 18, it seems that the device's response to the CONTROL IN requests is slow.

As I mentioned earlier, you can also try the workaround mentioned in this thread CYUSB3013 low control read performance with FX3 SDK library versions 1.3.2 and higher so that the performance of EP0 can be increased.

Please refer to this thread FX3: slow data rate from EP0 when DMA is active where the customer sees a similar problem.

Also, from the firmware shared, I see that CyU3PDebugPrint API is called in the DMA callback. Please do not call CyU3PDebugPrint API in the callbacks. You can either set events or use a global variable for tracking failures

Please confirm if that the streaming doesn't stop permanently with SKD 1.3.4.

Delay expected on the CONTROL IN endpoint as all channels are suspended before Control IN transfer. But the BULK endpoint is expected to work again. From the traces shared in response 18, the BULK IN transfers are working after the CONTROL IN transfer is done

As confirmed by you, that both bulk-in and control-in are working well i.e. without any data corruption under CyU3PUsbSetEpSuspDisableMask, But we do not recommend using this as this will lead to the problem mentioned in 4th point of section 2.3. FX3 troubleshooting guide.

Regards,

Rashi

Regards,
Rashi
0 Likes