Hi, I've referred AN75779 doc to accomplish that for our project.
Now, we want to change the transmission mechanism:
Dummy state machine:
According to Getting Started doc, I've understood the mechanism for dual sockets yield:
The normal step behavior which use dual socket should like:
However, now, each HREF may receive different type of data. I worry it may cause Socket Linked List conflict...
Ex: HREF1 – image, HREF2 – info, HREF3 – image, HREF4 – image
My inference step behavior:
In the step 1, load the DMA Descriptor1 on socket1(thread1). However, the next image data is received by socket0, not the expected socket1.
Q1: Will it cause the conflict as the following fig and cause crash for USB transmission?
Q2: If the answer for Q1 is yes. Can I use the commands in FW to reset Socket Linked List to avoid the conflict?CyU3PDmaMultiChannelReset(&glChHandleSlFifoPtoU);
CyU3PDmaMultiChannelSetXfer(&glChHandleSlFifoPtoU, 0, 0);
CyU3PDmaMultiChannelSetXfer(&glChHandleSlFifoPtoU, 0, 1);
Thanks for your patience to read it. Any help will be highly appreciated!Show Less
We intend to use a camera module (sensor + FPGA) with the FX3 and UVC to the Host like in AN75779.
The module outputs VGA@60fps but has a pretty low pixel clock (20MHz).
I’m trying to check if the module timing is compatible with the GPIF state machine as described in AN75779.
I’m struggling to find information in the spec/appnote/community on the shortest horizontal and vertical blanking times or clock cycles required.
As far as I understand AN75779 GPIF state machine:
Is my understanding correct ?
Is there a minimum time (for a given CPU clock) I can take in account for the vertical blanking?
Thanks in advance
For my project, I'm currently using the FX3 (CYUSB3014) and looked into the SPI GPIO bit banging example as reference for the bit banging approach and given my timing requirements, it seems that we would need a delay less than a microsecond in between bits. From the looks of it, the smallest delay that can be used is with the CyU3PBusyWait (1uS). Is it possible to sample the logic levels of the GPIO pin/s with smaller delays and perform bit banging at a faster rate?
I'm feeling a little out of my depth here as I'm a System Administrator rather than a seasoned Electronics Engineer, I hope this question makes sense...
I am trying to upgrade two machines, that each have several Cypress Westbrige devices attached to them, from Ubuntu 16.04 to Ubuntu 20.04. With Ubuntu 16.04, all devices enumerate correctly first as 04b4:00f3 and then go on to download their custom firmware, detach and reattach. However, with 20.04 I get the following errors:
Feb 23 12:05:47 master kernel: usb 1-6-port1: status 0101, change 0000, 12 Mb/s Feb 23 12:05:47 master kernel: usb 1-6-port1: indicator auto status 0 Feb 23 12:05:47 master kernel: usb 1-6.1: new full-speed USB device number 3 using xhci_hcd Feb 23 12:05:47 master kernel: usb 1-6.1: device descriptor read/64, error -32 Feb 23 12:05:47 master kernel: usb 1-6.1: device descriptor read/64, error -32 Feb 23 12:05:47 master kernel: usb 1-6.1: new full-speed USB device number 4 using xhci_hcd Feb 23 12:05:47 master kernel: usb 1-6.1: device descriptor read/64, error -32 Feb 23 12:05:48 master kernel: usb 1-6.1: device descriptor read/64, error -32 Feb 23 12:05:48 master kernel: usb 1-6-port1: attempt power cycle Feb 23 12:05:48 master kernel: usb 1-6-port1: not enabled, trying reset again... Feb 23 12:05:48 master kernel: usb 1-6.1: new full-speed USB device number 5 using xhci_hcd Feb 23 12:05:48 master kernel: usb 1-6.1: Device not responding to setup address. Feb 23 12:05:48 master kernel: usb 1-6.1: Device not responding to setup address. Feb 23 12:05:49 master kernel: usb 1-6.1: device not accepting address 5, error -71 Feb 23 12:05:49 master kernel: usb 1-6.1: new full-speed USB device number 6 using xhci_hcd Feb 23 12:05:49 master kernel: usb 1-6.1: Device not responding to setup address. Feb 23 12:05:49 master kernel: usb 1-6.1: Device not responding to setup address. Feb 23 12:05:49 master kernel: usb 1-6.1: device not accepting address 6, error -71 Feb 23 12:05:49 master kernel: usb 1-6-port1: unable to enumerate USB device
Two other similar devices connected to this machine at 1-6.3 and 1-6.4 show identical errors.
I have tried:
Have any other users experienced similar problems Cypress FX3 based devices when running Ubuntu 20.04?
AMCAP application unable to display any data on its screen. On PC side we are able to see data through USB analyser but not on the AMCAP application.
Image sensor: AR1335
AR1335 configured with : RAW8 , 640*480 @ 2FPS and CSI clock-160MHz
CX3 MIPI Configurations :
INPUT video format : RAW8
OUTPUT video format : 24bit
640*480 @ 6FPS and CSI clock-160
CyU3PMipicsiDataFormat_t dataFormat : CY_U3P_CSI_DF_YUV422_8_2 (also tried CY_U3P_CSI_DF_RGB888 , CY_U3P_CSI_DF_RGB565_2 )
Number of bits per pixel: 16 (8 bit also tried )
Width in pixel: 320 (640 also tried)
0x59, 0x55, 0x59, 0x32, /*MEDIASUBTYPE_YUY2 GUID: 32595559-0000-0010-8000-00AA00389B71 */
0x00,0x00,0xe1,0x00, Min bit rate (bits/s):14745600=640*480*8*6
0x00,0x00,0xe1,0x00, Max bit rate (bits/s):14745600=640*480*8*6
0x00,0xb0,0x04,0x00, Maximum video or still frame size in bytes(Deprecated) 640*380
CX3- log :
TimeDiff = 10686 ms FPS = 2
Prod = 18 Cons = 18 Prtl_Sz = 28512 Frm_Cnt = 31 Frm_Sz = 691200 B
Prod = 18 Cons = 18 Prtl_Sz = 28512 Frm_Cnt = 32 Frm_Sz = 691200 B
Prod = 18 Cons = 18 Prtl_Sz = 28512 Frm_Cnt = 33 Frm_Sz = 691200 B
Prod = 18 Cons = 18 Prtl_Sz = 28512 Frm_Cnt = 34 Frm_Sz = 691200 B
I made my custom board(FX3 and Camera Module).
I connected it and wrote my custom source code.
The black screen was printed in AMCAP, so I checked the debug message with wireshark.
The Wireshark confirmed that the data was output.
The resolution is 340(W) x 260(H), 30fps and 12bit data output.
You can see data in wireshark log.
I tried to change DMA Buffer size(CY_FX_EP_BULK_VIDEO_PKT_SIZE and CY_FX_EP_BULK_VIDEO_PKTS_COUNT ) in uvc.h
If i change buffer size, the buffers in the data packet are output differently.
你好，我使用一个uvc工具验证发送设置camera 图像对比度，饱和度命令，但是CyU3PUsbRegisterSetupCallback(CyCx3AppUSBSetupCB, CyTrue)注册的回调函数不响应，函数头里加了日志也没有通过串口打印出来。此uvc工具直接测试usb camera摄像头是有效果的。我想咨询一下，fx3需要如何注册回调函数才会响应类似命令？Show Less
I am a very new at hardware programming.
I try to solve next task.
Some board continuously generates a 16-bit data and clock. Signal data must be transferred to the PC via USB. This board doesn't have any control signals, any adresses and any flags. Only 16-bit data and clock. I use CyUSB3KIT-003 to connect my board with PC. The board is already connected to CyUSB3KIT-003 via GPIO 0-15 (for data) and GPIO 16 (for clock). It needs set up CyUSB3KIT-003 for transfer data to to the PC via USB.
I think I can use "The synchronous Slave FIFO interface of EZ-USB® FX3™ " example described at AN65974 document to solve my task. But I'm not sure.
Help me please understand next points. First, should I use GPIF in my case or not? Maybe there is some other easier way? And, secondly, If it needs use GPIF, is there some fixed sequence for creating interface?
Also I will be grateful for any advice for solving this task.Show Less
Hi, there are two GPIF threads which are similar to AN75779's mechanism in my project, and it can transfer image data smoothly.
Now, I’m researching GPIFII’s "DMA ready" ability. Therefore, I’ve TWO questions for that.
Q1: In the GPIFII - Interface Definition tab, I set the DMA flags: 2
And my flag setting
After this setting, the corresponding pin will output HIGH while the DMA thread X is ready, and output LOW while the DMA thread X is preparing?
Q2: If I just want to use "DMA ready" ability, I can use FW api - CyU3PGpifOutputConfigure() to TOTALLY REPLACE Q1’s GPIFII setting?
Why I ask that? Because I found if I programmed the code as
The "DMA ready" pins still output the signal, even though I DON'T set the Q1’s setting.
Any help will be highly appreciated!Show Less