USB superspeed peripherals

Hi, 

I am currently working with CX3 device in order to get full-frame from CIS sensor. I have enabled several Processing Units(PU) in order to have a handshaking with sensor, and control it.

It works fine in Windows, working under UVC. But I am having problems in Ubuntu, working under V4L2.

It is a few strange, because the device is running with the same firmware, so I guess there is something wrong either uvcdscr.c or uvc.c file.

Please, could you tell me if it's common having problems between UVC and V4L2? Have I to configure the Processing Units on different way?

I have attached both uvcdscr.c and uvc.c files.

Thanks so much.

I Load the GPIF configuration for Slave FIFO sync mode.

And start GPIF state machine by using this api CyU3PGpifSMStart(RESET, ALPHA_RESET);

Whole configuration is done like 

###### See GPIF_config.PNG  ##### 

Now I need the RESET the GPIF configuration.

###  see attach file GPIF_reset.PNG ###

I try these api

1) Is this correct ??

2) How to change the State of GPIF by using CyU3PGpifSMSwitch() ??

                          comment : CyU3PGpifSMSwitch() is successful but state is not changed ?

3) If GPIF state change to RESET and then change to IDEAL, Is equivalent to GPIF RESET ??

My requirement is to RD/WR the register from FPGA with RESET whenever user wants.

Hi,

  I am working on a Denebola CX3 Kit which comes with a OV5640 image sensor. I used the sample application "Cx3UvcOV5640" and flashed the board. I am able to see the video on e-CamView and it works fine. I am trying to get some logs from the device so that I can view it on my serial console (Tera term). The USB COM port comes up on the PC, but I am not able to see any messages.

I am sending messages via the serial console using CyU3PDebugPrint().  CX3_DEBUG_ENABLED  is also set to 1.

Any idea why I am not seeing the debug logs on my PC.

Please provide any examples to view serial logs.

Thanks and Regards,

Subbu

Hi,

I am trying to modify FX3 cyfxmscdemo app to set an interface from usb to fpga over gpif. 
I use the following APIs,
--
In Scsi Read10 case,
CyU3PDmaChannelSetupRecvBuffer (&glChHandleBulkPtoU, &dmaBuf) //  receive from fgpa to temp buffer
CyU3PDmaChannelSetupSendBuffer (&glChHandleBulkPtoU, &dmaBuf) // send temp buffer to usb host

In Scsi Write10 case,
CyU3PDmaChannelSetupRecvBuffer (&glChHandleBulkUtoP, &dmaBuf) //  receive from usb host to temp buffer
CyU3PDmaChannelSetupSendBuffer (&glChHandleBulkUtoP, &dmaBuf) // send temp buffer to fpga
--

However, this temp buffer (glMscStorageDeviceMemory) has limited capacity due to FX3 ram size. 
Current usb3 speeds may send 2048 numBlks (2048x512 byte=1MByte), which cannot be stored in this temp buffer. I can correctly format fpga ddr memory using above functions by limiting numBlks count in Linux side. 

Now, I want to get rid of this buffer and directly send data from usb to fpga and vice versa. Thus, I noticed CyU3PDmaChannelSetXfer() API in cyfx3s_msc app and I changed above functions with the following ones

In Scsi Read10 case,
CyU3PDmaChannelSetXfer(&glChHandleBulkPtoU, numBlks*glLunBlkSize) // send from fpga to usb host(??)

In Scsi Write10 case,
CyU3PDmaChannelSetXfer(&glChHandleBulkUtoP, numBlks*glLunBlkSize) // send from usb host to fpga (??)

I suppose that should directly transfer data in both directions in the dma channels without involving any buffer, right?

The problem is that, host msc driver first sends read10 cmd (lba:0 and numBlks:1). Then fpga correctly send data to usb host. I can both observe that data correctly in fpga chipscope and in Wireshark usb protocol in Linux .  However, Read10 acknowledge does not appear in Wireshark usb protocol.(I think it should come from FX3 msc driver?) And usb connection freezes after that and does not send any further read10 cmds.

I wonder that, is there anything that I am missing? Can't I use CyU3PDmaChannelSetXfer() in this case? How can I further debug?

Thanks in advance.

Hello,

Our CX3 I2C is not working properly, looks like only sometimes in random we mange to communicate with our camera module. lookin at the signals we see that the rise time is high as well as the frequency is not as it should, it is 250KHz instead of 400KHz. this is with 10K pull-up resistors as it is in the reference design.

we tried changing the pull-up to 5KHz, this had an impact, mainly on the frequency which changed to 280KHz.
Then we saw in the FX3 checklist that it is recommended to use 2K pull-up (it is for flash but we decided to try) and the signal changed to 400KHz but the rise time is still bad

any suggestions? there is nothing on the I2C lines that is loading them (the signals remain similar with and without the camera module).

attached also the schematics and layout.

thanks, 

We've created a custom board containing a CYUSB3014-BZXC with a GPIF interface attached to a Spartan 7 FPGA. My GPIF state machine is very similar to the SlaveFifo design desribed in AN65974, with two primary differences:
1. I've removed the SLCS signal. We use a GPIO pin to tell the FPGA when the host application has enabled the interface. The FX3 still provides FLAGA and FLAGB and they are connected to Current_Thread_DMA_Ready and Current_Thread_DMA_Watermark. The FPGA controls the remaining signals (SLRD#, SLOE#, SLWR#, PKTEND#, and A[1:0]).
2. The FX3 sources PCLK but it is still a slave design. This was done so that a separate GPIF design can be used to configure the FPGA in Slave SelectMap mode.

When the host initiates a data transfer the FX3 firmware creates a multichannel DMA between USB OUT endpoint 3 and GPIF threads 2 and 3 and allocates two 16K buffers if the transfer involves OUT data. If the transfer involves IN data then the firmware creates a multichannel DMA between USB IN endpoint 4 and GPIF threads 0 and 1 and allocates two 16K buffers. If the transfer is bi-directional then both DMA channels are created and the buffer sizes are the same as in the unidirectional case.

When the host wants to transfer data it first sends a command to the FX3 to tell it to enable the GPIF interface. This will cause the PIB clocks to be configured and the state machine to be loaded, and then the enable signal to the FPGA is driven to a '1'.

The host test application can be configured to perform OUT only transfers, IN only transfers, or bidirectional transfers with data verification in a loop. Each time the host enters this loop it sends a 16 byte command to the FPGA that tells it which direction the transfer will be, and if data is to be written too/read from a 16K BRAM FIFO that exists inside the FPGA or data read from the FPGA Is simply discarded, and data written from the FPGA is from a counter instead of the FIFO. The command includes OUT and IN byte counts so that the FPGA knows how much data to transfer in each direction.

After the command is downloaded the bulk data transfer begins. For OUT only transfers the data is read by the FPGA over the Slave Fifo interface and discarded. For IN only transfers the FPGA will writes the value of an internal counter to the FX3. For bidirectional transfers the FPGA first reads a buffer of data from the FX3 (address 2 or 3, alternating on each FX3 read, always start on address 2) into the BRAM FIFO and then writes the BRAM FIFO to the FX3 (address 0 or 1, always starting on address 0, alternates on each FX3 write, always starting on address 0). The process is repeated with addresses toggling between each transfer until all data is transferred.

Once the bulk data transfer completes several smaller transfers are performed to read statistic registers that are inside the FPGA. Those statistics include how many times the FPGA thinks that it asserted SLOE, SLRD, SLWR, and PKTEND. They also include the last 32 OUT addresses, the last 32 IN addresses, and in the case that the transaction is aborted by the host due to timeout, it also includes the address that the FPGA thinks that it will read or write next and the count of words presently in the BRAM FIFO.

If the test is supposed to be performed for more than one iteration then it loops.

Testing has shown that unidirectional OUT transfers and unidirectional IN transfer work reliably at 100 MHz. Bidirectional transfers work reliably at 89.6 MHz, but will fail randomly when PCLK is set to 100 MHz (100.8).

When the bidirectional transfers fail the statistics collected from the FPGA show that the FPGA last received a buffer from the FX3 and wrote it into the BRAM FIFO and is in a state where it's waiting for FLAGA to indicate that there is an IN buffer available to write data to. The count of words in the BRAM FIFO is equal to 4096 and I can see that during the last 32 OUT's and IN's there have been now repeated READS or WRITES to the same address two times in a row, meaning that it correctly toggles the address each time. I can also see that the FPGA logic is waiting for an IN buffer on the correct address. However, it never receives one.

In the FX3 firmware I've setup a DMA callback on the producer endpoint (consumer was never signaled) of both the OUT and IN DMA channels. Each time the producer event occurs I increment the count of bytes transfered by 16K, but never exceeding the total size of the transfer, which may not be a multiple of 16K. The host application receives these counts after the transaction completes, or is aborted (fails). From this I can see that the FX3 thinks that it received one less 16K buffer than the FPGA thinks that it sent. This makes me think that the signal timing may be off and that a SLWR is being missed by the FX3. Is there a way for me to determine how many bytes are stored in the DMA buffer associated with socket 0 and socket 1 so that I can see if a word was missed?

Some other observations:
Our firmware outputs the USB PHY and Link error counts over UART once per second. During an OUT only transfer the error count stays at 0 when I run a large number of transfers. This is also true for an IN only transfer. However, when I perform the bidirectional transfer I see PHY errors reported each second. Why are there PHY errors during bi-directional transfers but not the uni-directional transfers?

1000 ms PHY errors = 12
1000 ms LINK errors = 0
1000 ms PHY errors = 6
1000 ms LINK errors = 0
1000 ms PHY errors = 11
1000 ms LINK errors = 0
1000 ms PHY errors = 12
1000 ms LINK errors = 0
1000 ms PHY errors = 6
1000 ms LINK errors = 0
1000 ms PHY errors = 12
1000 ms LINK errors = 0
1000 ms PHY errors = 12
1000 ms LINK errors = 0
1000 ms PHY errors = 6
1000 ms LINK errors = 0
1000 ms PHY errors = 10
1000 ms LINK errors = 0
1000 ms PHY errors = 11
1000 ms LINK errors = 0
1000 ms PHY errors = 12

I've registered a callback function to see if CYU3P_USBEP_SS_RESET_EVT occurs, but it does not.

Larger (160MB) bidirectional transfers fail much more frequently than small (16MB).

Our firmware sets the OUT and IN endpoint burst size to 16 by default. If I change it to 1 (disable burst) on both of the endpoints then bidirectional transfers NEVER fail, even at 100 MHz. I still see the same number of PHY errors that I did at 100 MHz so I'm not sure that the PHY error count is what ultimately causes IN transfers to stop.

Are the PHY errors what ultimately causes the IN transfers to stop, or is it something else?

Any suggestions on how to further debug this problem? I tried to capture the bus traffic with the Ellisys EX350 but that's very difficult because it seems to prevent the data transfer from failing, or at least makes it fail much less often, and the amount of data is so large that the capture stops.

Thanks,
Michael

My hardware is a sensor connected to 3014 via DVP. The problem is the DVP signals are good(frame/line valid and the pixel clock).  And we can see the firmware enter the CyFxUvcApplnDmaCallback(), however, then get the buffer from CyU3PDmaMultiChannelGetBuffer(), we found the dmaBuffer.count  is zero for every callback. The consequence is that the USB host receives many empty USB packages, and no image is presented. 

The interesting thing is if we try to reset 3014(may need a few times), it is probably recovering from the exception state.

Any idea for what's going on under this phenomenon?  Many thanks

Rossi

I designed a USB test module using CYUSB3014. This USB test module is used to test the USB HUB. The module runs the cyfxbulksrcsink example, and the circuit design completely refers to CYUSB3KIT-003.

I simulated some open-circuit and short-circuit faults of the superspeed signal on the USB HUB side, and then verified whether these faults can be detected by the CYUSB3014 module, and found that the following three fault tests failed:

1. SSRX_N open: Enumeration and data communication are completely normal.
2. SSTX_P shorted to GND: Enumeration and data communication are completely normal.
3. SSTX_N shorted to GND: Enumeration and data communication are completely normal.
4. SSRX_P shorted to GND: Enumeration and data communication are completely normal.
5. SSRX_N shorted to GND: Enumeration and data communication are completely normal.

What's the problem?

Is it possible to modify the firmware to solve all or some of the above problems?

If it can't be solved by modifying the firmware, what hardware circuit can solve the above problems, I hope to get your suggestions.