USB superspeed peripherals Forum Discussions
CyU3PMipicsiGetErrors (CyTrue, &errCnts);
CyU3PDebugPrint ("mipi err:frmErrCnt=%x,crcErrCnt=%x,mdlErrCnt=%x,ctlErrCnt=%x,eidErrCnt=%x,recrErrCnt=%x,unrcErrCnt=%x,recSyncErrCnt=%x,unrSyncErrCnt=%x\r\n",
errCnts.frmErrCnt,errCnts.crcErrCnt,errCnts.mdlErrCnt,errCnts.ctlErrCnt,
errCnts.eidErrCnt,errCnts.recrErrCnt,errCnts.unrcErrCnt,errCnts.recSyncErrCnt,errCnts.unrSyncErrCnt);
the print is :
mipierr:frmErrCnt=0,crcErrCnt=0,mdlErrCnt=4003D50C,ctlErrCnt=4000794C,eidErrCnt=4000A778,recrErrCnt=0,unrcErrCnt=0,recSyncErrCnt=0,unrSyncErrCnt=0
you see some format is print error,and the print format sometimes is print ok, some times error.
How to slove it?
Show Lesswhen I use potlayer to open cx3_uvc, the uvc device will commit camera data from DMA to UVC, use the api CyU3PDmaMultiChannelCommitBuffer,
and it will commit success 6 times,then it will stop.
the usb log catpured by wireshark is attachment,
what's wrong with it?
Show LessI use cx3 on ARM(RK3399 Ubuntu), the sensor is ov9282, 1280x800 @ 15fps, it always block in a minutes(about 30 minutes), there is no error, but can't get any frame data. The log is as below. "commit_num" is added by myself, to count the times of data commit to usb endpoint. When it is block, there is no error, and the "commit_num" also not update.
But on PC, also Ubuntu OS, it always ok.
Is there anyone have this issue, and give me spme suggestion?
UsbCB:Call AppStop CyCx3AppThread_Entry
AplnStop:SMState = 0x7
AplnStrt:CyCx3AppStart CyCx3AppStart
AplnStrt:SMState = 0x1
Prod = 83 Cons = 83 Prtl_Sz = 9520 Frm_Cnt = 308 Frm_Sz = 2048000 B
TimeDiff = -39 ms FPS = 0
UsbCB:Call AppStop CyCx3AppThread_Entry
AplnStop:SMState = 0x7
AplnStrt:CyCx3AppStart CyCx3AppStart
AplnStrt:SMState = 0x1
Prod = 83 Cons = 90 Prtl_Sz = 9520 Frm_Cnt = 309 Frm_Sz = 2048000 B
UsbCB:Call AppStop CyCx3AppThread_Entry
AplnStop:SMState = 0xA
AplnStrt:CyCx3AppStart CyCx3AppStart
AplnStrt:SMState = 0x2
UsbCB:Call AppStop CyCx3AppThread_Entry
AplnStop:SMState = 0x2
AplnStrt:CyCx3AppStart CyCx3AppStart
AplnStrt:SMState = 0x2
Prod = 62 Cons = 62 Prtl_Sz = 9520 Frm_Cnt = 310 Frm_Sz = 1532240 B
[CyCx3AppMipiErrorThread] commit_num = 26400
[CyCx3AppMipiErrorThread] commit_num = 32624
[CyCx3AppMipiErrorThread] commit_num = 38804
[CyCx3AppMipiErrorThread] commit_num = 39222
[CyCx3AppMipiErrorThread] commit_num = 39222
[CyCx3AppMipiErrorThread] commit_num = 39222
[CyCx3AppMipiErrorThread] commit_num = 39222
[CyCx3AppMipiErrorThread] commit_num = 39222
[CyCx3AppMipiErrorThread] commit_num = 39222
[CyCx3AppMipiErrorThread] commit_num = 39222
[CyCx3AppMipiErrorThread] commit_num = 39222
[CyCx3AppMipiErrorThread] commit_num = 39222
[CyCx3AppMipiErrorThread] commit_num = 39222
[CyCx3AppMipiErrorThread] commit_num = 39222
[CyCx3AppMipiErrorThread] commit_num = 39222
[CyCx3AppMipiErrorThread] commit_num = 39222
[CyCx3AppMipiErrorThread] commit_num = 39222
Show LessHi everyone.
I'm using CX3 to transfer image data to Jetson Xavier board through USB port.
I'm using cyusb_bulk_transfer function and there is a problem of timeout.
When I check the packet transfer time, each packet tranfer usually takes 300 us but sometimes it takes 280000 us.
It causes severe frame drops of my system.
Is this due to CPU resources or an intrinsic problem of bulk data transfer?
Thank you in advance.
Show LessHello
I'd like to interface FX3 with an Standard resolution S-VIDEO encoder (Analog device ADV7280A)
I need some advice in order to modify the UVC AN75779 to works with a Interlaced video signal.
At the moment I'm able to get a 720x288 video.
I think there are some modification to do in the payload header and to the configuration descriptor.
Show LessHi,
We have had issues of seeing write errors (XferData fails on an out endpoint) in one of our products that uses FX3 as the main chip. This issue only occurs when the port is connected to a USB 3.1 host controller. We tried on several machines with different motherboards and we noticed the issue on all of them which rules out the possibility of a bad USB port or an issue in the motherboard. We looked at the USB3 traffics using Beagle USB 5000 analyzer, but it doesn't detect any issue and the packet seem to be sent successfully (despite the fact that the cypress driver returns an error). The issue is hard to reproduce as it doesn't always happen, but we are sure that it never happens on a USB3.0 host controller. My speculation is that the Cypress driver has some issues with USB3.1 host controllers.
Has anyone else noticed or is having the same issue?
Any thoughts most appreciated.
Hamid
Show LessWhen can we expect to see Cypress' support for USB 4.0.
The spec is expected to be released in late 2019.
Cypress as a USB leader, is likely well aligned.
Is Cypress able to update the USB Controllers Roadmap with their plans for various USB 4.0 products?
https://www.cypress.com/cypress-product-roadmaps
Greg
Show LessI have a simple application which streams data to an FX3 via the GPIF-II. I'm using 16-bit mode, external clock & slave mode. My GPIF-II state machine has only two states, IDLE and IN which accepts data (IN_ADDR, IN_DATA, repeat actions). I'm using SLWR_N in my state machine, but it's hard-wired to low for now (asserted). I use the STREAMER application to receive data. My IN endpoint is BULK, 1024, 16 burst, CY_U3P_DMA_TYPE_AUTO_MANY_TO_ONE. I also use A0 and A1, toggling A0 every 8192 clocks and A1 every 4096 clocks.
In Streamer, I can choose almost any buffer size (packets per Xfer). For example, 16 thru 128 all work, BUT ONLY when Xfers to Queue is set to 1. In that case, I get the data I expect at the rate I expect (25MHz external clock = 50 MB/s).
However, if I use 32/8 for the packets and xfers, the first megabyte transfers correctly, then each subsequent xfer fails and times out. After that, it gets 1 good xfer, then times out again, 1 good, then times out, etc. This occurs when Xfers to Queue is anything other than 1. The behavior is consistent, regardless of the time out value.
The fact that the data rate is correct when Xfer to Queue == 1 seems to suggest my slave interface must be working. I have confirmed all GPIF I/O with a logic analyzer.
Has anyone seen this? I'm sure it's something dumb on my part.
Show LessWhy does enabling the USB_DEBUG_INTERFACE in the AN75779 code using SDK version 1.3.4 let the firmware run under the debugger when the debugger has problems with it disabled.
This question is not on how to use the USB_DEBUG_INTERFACE or how it works;
This question is to understand what else may be affected due to a known issue with the debugger in 1.3.4 as discussed in Community Post FX3 SDK version 1.3.4 won't put breakpoints while running
Greg