DMA type for PIB producer and USB consumer

[jnagy]

I have a GPIF state machine gathering video data from an FPGA FIFO and the goal is to retrieve this data, attach UVC headers and then send it to the USB host, however I am unsure what DMA type I should be using to do this and how it should be done. Looking at the code for the CyU3PDmaType_t enum in cyu3dma.h, "CY_U3P_DMA_TYPE_MANUAL_OUT" is for CPU to consumer, socket "CY_U3P_DMA_TYPE_MANUAL_IN" for producer socket to CPU and "CY_U3P_DMA_TYPE_MANUAL" simply says "Manual mode DMA channel". How do I know which DMA type I should use?  The example I am basing my firmware on uses Manual OUT however my data is coming from a GPIF PIB socket, not the CPU. Also, since I want to intercept the data before it goes to the host to attach headers, do I need 2 channels (GPIF -> firmware and firmware -> USB) or can I use GPIF's "INTR_CPU" or DMA callbacks to attach the header before committing the data to the USB host?

[Bakal]

Hello,

If you want to send data from GPIF PIB socket to the USB and want to attach headers, there is no need to use two channels, you can use "CY_U3P_DMA_TYPE_MANUAL" DMA channel. 

Also, please refer to AN75779 UVC application firmware, it will give you clear idea as it applies the same application as yours. Add both producer and consumer event in the DMA channel creation so that you will get callback accordingly.

If you want to understand the Manual channel, please refer to:
C:\Program Files (x86) \Cypress\EZ-USB FX3 SDK\1.3\firmware\dma_examples\cyfxbulklpmanual 

Thanks,
Sakshi Bakal.

[jnagy]

I have switched over to using CY_U3P_DMA_TYPE_MANUAL and am still having issues. While reading through the documentation, I read that there are some restrictions on which DMA sockets can be configured with the GPIF threads. Below I have listed my DMA structure and from my understanding this should be correct. Can you verify?

- GPIF is reading from a FIFO only using Thread 0 using the 2bit FIFO example as base.
- Firmware is using "CyU3PGpifSocketConfigure" in my GPIF init function to associate "CY_U3P_PIB_SOCKET_0" with Thread 0.
- DMA channel is created in ApplnStart function with "prodSckID = CY_U3P_PIB_SOCKET_0" and "consSckID = CY_U3P_UIB_SOCKET_CONS_1". DMA channel has a callback for "CY_U3P_DMA_CB_PROD_EVENT" events.
- In the DMA callback, the buffer is gotten with CyU3PDmaChannelGetBuffer, header are inserted and then sent with CyU3PDmaChannelCommitBuffer.

Thanks,

[Bakal]

Hello,

Your listed DMA structure is correct.  Let me know what issues you are facing. 

Also, make sure that 'Thread 0' is driven by FPGA properly. 
Please share your updated firmware.

Thanks,
Sakshi Bakal

[jnagy]

The issue is that my firmware doesn't seem to be communicating with the FIFO correctly, namely with setting the watermark at the correct size and the firmware actually retrieving data from the FIFO. 

For the watermark, I want it to go off when the FIFO has 15,372 bytes or more. My GPIF state machine is configured for a 32-bit address bus so the 15,372 bytes is 3843 32-bit words. Currently my firmware is configured for 4 buffers with each buffer having a size of  16 * 1024 byte packets (USB burst of 16). The watermark would obviously start off as there is no data in the FIFO on boot. Using a formula I found on another post (watermark * (32/bus width) - 4 = size number of bus width words), I inserted my values of GPIF bus width = 32 and size number of bus width words = 3843. This solves for a watermark value of 3847 however we see the watermark is being set on bootup in the FPGA. In the TRM under "GPIF_THREAD_CONFIG" we found that the that the watermark position is subtracted from the "end of usable space" but as I am using the CyU3PGpifSocketConfigure API I thought the library would make the adjustment for me.

Regarding retrieving data from the FIFO, I think that my firmware is configured to draw data from the FPGA's FIFO however when I open my application up in the Windows Camera app I just get a black screen. I am not sure why this is. The FPGA is writing data to the FIFO but my firmware is either not seeing/taking it or wrapping and sending the UVC data incorrectly.  With my setup I don't have access to UART debug logs so it is difficult to know what exactly is happening. I have a DMA override mode which replaces the DMA and GPIF with manually inserted frames and the Camera app can see these frames without issue, so I think the problem is on the FIFO side as opposed to the UVC side.

I have included in my post the most updated firmware and a wireshark log of writing the firmware, opening up the device in the Camera app and then closing the Camera application. Edit: I found in the USB Frame descriptor was using 1080p30 frame timing values instead of 1080p60. I fixed the descriptor and reuploaded a wireshark capture with the new firmware.

[jnagy]

After looking at the FPGA FIFO setup I have a few questions on how GPIF works.

1. How does the GPIF state machine convert a read buffer of FIFO data into a "CY_U3P_DMA_CB_PROD_EVENT" DMA callback? Does GPIF generate this callback on an "IN_DATA" or any other action? Does it get produced when PKEND is asserted or when the current filling buffer gets full of read data?
2. What controls whether a short or full FIFO buffer is read? My understanding is that the PKEND input controls whether the FIFO data read is 1 full buffer's worth or not. Also that PKEND has no direct effect on the firmware or its operation - PKEND just impacts the state machine which will then impact the firmware depending on the state actions the resulting state has, such as "INTR_CPU".
3. What exactly does "CyU3PDmaSocketSetWrapUp" do in the AN75779 example? Does "CyU3PDmaSocketSetWrapUp" ensure the buffer is marked in software as 'complete' and then a "CY_U3P_DMA_CB_PROD_EVENT" is generated?
4. What exactly does "CyU3PGpifControlSWInput" do in the AN75779 example? Is this something that should always be included in GPIF control firmware? It seems like it resets the GPIF state machine in some way.

Thanks,

[jnagy]

Hello,

I was wondering if you had the chance to look at the firmware and possibly see what is wrong?

Thanks,

[Bakal]

Hello,

Can you please reshare your firmware zip folder, it is giving me an issue as I'm trying to open the file.

Regards,
Sakshi Bakal

[jnagy]

I have included a zip of the project.

[jnagy]

Have you been able to find any issues with the firmware?

[Bakal · Accepted solution]

Hello,

I apologize for the late response,
1. What exactly does "CyU3PDmaSocketSetWrapUp" do in the AN75779 example? Does "CyU3PDmaSocketSetWrapUp" ensure the buffer is marked in the software as 'complete' and then a "CY_U3P_DMA_CB_PROD_EVENT" is generated?
>>This function sets the bit that forces a socket with a partially filled buffer to wrap up the buffer. The function does not wait for the socket to wrap up. 

2. What exactly does "CyU3PGpifControlSWInput" do in the AN75779 example? Is this something that should always be included in GPIF control firmware? It seems like it resets the GPIF state machine in some way.
>> The GPIF hardware supports one software-driven internal input signal that can be used to control/direct the state machine functionality. This function is used to set the state of this input signal to a desired value

I would suggest you to refer the UVC application for a better understanding of Manual Channel and its callback events. 

Regards,
Sakshi Bakal