FX3 Current_Thread_DMA_Ready flag goes active low after thread address is set.

[AnKi_4737686]

I am using a FPGA to write video and audio data to the FX3 using a multichannel slave FIFO. Occasionally when using a slow PC the video stalls but audio keeps playing. I've noticed some applications handle this (zoom) but others don't (VLC).

I've looked at the Current_Thread_DMA_Ready flag and the video thread on a scope. It seems that the Current_Thread_DMA_Ready flag indicates that the FIFO is not full until the video thread is set. I am certain that no video data was written to the FX3 since this video stall had occurred. I have tried to reset the DMA immediately after the video stalls, but this seemed to have no effect. There are no error messages when using UART to debug either.

Is there any way to handle a video stall while streaming without depending on the host application?

[Rashi_Vatsa]

Hello,

From the description, I understand that on a slower PC the video gets stalled. And after this stall, no data is written to FX3 from FGPA. Is this correct?

I have a few questions:

- Please let me know what happens when the video is streamed through a host application like zoom. How does it recover?

- I understand that the Current_Thread_DMA_Ready flag is the flag showing the status of the DMA buffer associated with the currently addressed channel. But please let me know what is the video thread?

- "It seems that the Current_Thread_DMA_Ready flag indicates that the FIFO is not full until the video thread is set" Can you please share the scope traces for us to understand the problem

- As mentioned in the title the Current_Thread_DMA_Ready goes low after the thread address is set. Please let me know when does this happens. Is it the cause of the video stall or does it happen as a consequence when the stall happens? It is possible that the DMA buffer might not be consumed by the USB block when the thread address is set and that can be a reason the DMA Ready flag going active low.

- What is the video resolution and the frame rate at which the video is being streamed?

Regards,

Rashi

[AnKi_4737686]

Hello,

>>From the description, I understand that on a slower PC the video gets stalled. And after this stall, no data is written to FX3 from FGPA. Is >>this correct?

Yes.

>>Please let me know what happens when the video is streamed through a host application like zoom. How does it recover?

It appears there is a setup callback with the following:

• bmRequest = CY_U3P_USB_TARGET_ENDPT
• bRequest = CY_U3P_USB_SC_CLEAR_FEATURE

After that there is two more events that occur before the video begins streaming again:

• UVC_PRE_START_EVENT
• UVC_SETCUR_COMMIT_EVENT

>>I understand that the Current_Thread_DMA_Ready flag is the flag showing the status of the DMA buffer associated with the currently >>addressed channel. But please let me know what is the video thread?

Please excuse my lack of knowledge here. I'm a hardware engineer trying to debug the software.

The video thread I am referring to is the current addressed channel. The address associated with the video DMA buffer is 0x00 and 0x01. In my design there are four total addresses which I believe are associated with the PIB socket.

• Video: CY_U3P_PIB_SOCKET_0, CY_U3P_PIB_SOCKET_1
• Audio: CY_U3P_PIB_SOCKET_2
• Controls: CY_U3P_PIB_SOCKET_3

>>"It seems that the Current_Thread_DMA_Ready flag indicates that the FIFO is not full until the video thread is set" Can you please share >>the scope traces for us to understand the problem.

Based on your last question, the Current_Thread_DMA_Ready flag is actually high when the address is set to the audioDMA buffer (0x02) and immediately goes low once the address is set to the video DMA buffer (0x00). This leads me to believe there must be an issue reseting the video DMA buffers. I've attached a document with some scope shots that will hopefully clarify this.

>>As mentioned in the title the Current_Thread_DMA_Ready goes low after the thread address is set. Please let me know when does this happens. Is it the cause of the >>video stall or does it happen as a consequence when the stall happens?

I can't say with confidence that this happens before or after the stall occurs.

>>It is possible that the DMA buffer might not be consumed by the USB block when the thread address is set and that can be a reason the DMA Ready flag going active >>low.

This seems to be the most likely cause of the video stall.

>>What is the video resolution and the frame rate at which the video is being streamed?

1920x1080 @60fps. The frame rate of the video media player will vary from this based on bandwidth.

Thanks,

Andy

[Rashi_Vatsa · Accepted solution]

Hello Andy,

Thank you for the traces.

From the traces, it seems like the DMA buffers are not empty/ consumed by the USB.

To confirm this we can check the producers and consumers' events.

- Please let me know which firmware are you using as the base of your application. Is it based on the AN75779 or SlaveFIFO (AN65974)

- Please let me know if the is the Video DMA channel is a Manual DMA channel or an AUTO DMA channel.

- Also, let me know the DMA buffer size used for the video channel

If the DMA channel is a Manual DMA channel, please register for the producer and consumer events and track those events in the DMA callback and print the values in the for{}.

You can also check if CyU3PDmaMultiChannelCommitBuffer API fails or executes successfully.

If DMA manual channel is used, for tracking  the producer and consumer events

- Register for the DMA events

dmaMultiConfig.notification   = CY_U3P_DMA_CB_PROD_EVENT | CY_U3P_DMA_CB_CONS_EVENT;

dmaMultiConfig.cb             = CyFxUvcApplnDmaCallback;

    apiRetStatus = CyU3PDmaMultiChannelCreate (&glChHandleUVCStream, CY_U3P_DMA_TYPE_MANUAL_MANY_TO_ONE,

            &dmaMultiConfig);             \\ Manual Channel

- Track the events in DMA callback

void

CyFxUvcApplnDmaCallback (

        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)

    {

       ......    

/* Commit Buffer to USB*/

            status = CyU3PDmaMultiChannelCommitBuffer (chHandle, (dmaBuffer.count + CY_FX_UVC_MAX_HEADER), 0);

            if (status == CY_U3P_SUCCESS)

            {

                  RxCount++;

            }

else if (type == CY_U3P_DMA_CB_CONS_EVENT)

    {

          TxCount++;

     }

- Print the values inf for {; ; }

CyU3PDebugPrint (4, "UVC: buffer recived %d and buffer consumed %d r\n", RxCount,TxCount);

Please share the UART debug prints if the DMA channel is a Manual Channel

Regards,

Rashi

[AnKi_4737686]

Hi Rashi,

The firmware I am using is based on SlaveFIFO (AN65974) firmware.

The Video DMA multichannel is CY_U3P_DMA_TYPE_AUTO_MANY_TO_ONE.

The DMA buffer size is 16KB.

Is the Manual DMA channel the only way I can properly debug the DMA status?

Thanks,

Andy

[Rashi_Vatsa]

Hello Andy,

When the DMA channel is CY_U3P_DMA_TYPE_AUTO_MANY_TO_ONE the producer and consumer events are not triggered. For multi-channel DMA buffer, only the manual channel triggers the producer and consumer events when registered.

- To debug the problem can you change the DMA channel to the Manual channel and check the prod and cons events.

- As the problem is seen with the slow PC only, can you also try to increase the DMA buffer size to 32 KB and set the DMA count to 3 and let me know the result

Regards,

Rashi