- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
device ack cur gain
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
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 .
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- control out/in very fast in 22us, cx3 need > 30ms after streaming.
- don't break down video transfer.
so, Unknown type 81 status is not the problem.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rashi