3 Replies Latest reply on Sep 3, 2018 11:36 PM by wu.zhijian_1557526

    end point stop transmit data and cannot be reset

    wu.zhijian_1557526

      Hi,

       

      My new design is a composite device which have 1 UVC channel and 2 UAC channels.

      The UVC channel could support 3840x2160P30 @ NV12, and UAC are both work in 48KHz mode.

       

      Now the problem is that after few minutes, one UAC channel will stop transmitting audio data and instead of transmitting some zero payload package to the host.

      the other UAC channel will turn to transmit zero payload packet after half hour or one hour. The UVC channel always works fine.

       

      So I checked the DMA channel status both of the UAC DMA channel status is in "CY_U3P_DMA_ACTIVE". Then I checked PIB, no errors found.

      But on the GPIF interface the thread flag of the two UAC channel cannot asset anymore.

       

      And I tried CyU3PUsbEnableEPPrefetch()  and CyU3PUsbEPSetBurstMoe(), nothing changed.

       

      Because of that sometimes the device  halted and no response to the host, I think maybe there will be a stack overflow or something like that.

       

      Any suggestion how I could locate the error?

       

      Best regards

       

      Wu 

        • 1. Re: end point stop transmit data and cannot be reset
          wu.zhijian_1557526

          Hi,

           

          I keep on using CyU3PDmaChannelGetStatus() to watch the two UAC dma channel status. And found something abnormal.

           

          1, using

               CyU3PDebugStringPrint(buffer, USBUART_DMA_BUF_SIZE, "UAC1: %x %x\r\n", state, consXferCount - prodXferCount);

          I found that the diffrence between prodXferCount and consXferCount keep on increasing. Normally the diffrence should be keet in a small value, the difffrence between should means that some data didn't be sent out on time and still stay in RAM.  but after an hour, the value could be 0x5xxxx, which looks like that is 320K DWORD data stay in RAM. I don't think that the FX3 have so many ram to store them.

           

          2. I use codes below to try send out data

          if (consXferCount == prodXferCount)

          {

              status[0] = CyU3PDmaChannelGetBuffer(&glUacStreamHandle[1], &buffer_tx, 0);

               status[1] = CyU3PDmaChannelCommitBuffer (&glUacStreamHandle[1], CY_FX3_ISO_XFER_LEN, 0);

               status[2] = CyU3PDmaChannelSetWrapUp (&glUacStreamHandle[1]);

               CyU3PDebugStringPrint(buffer, USBUART_DMA_BUF_SIZE, "UAC Buffer: %x %x %x\r\n", status[0], status[1], status[2]);

          }   

               and get status[0] = 0x47, status[1]=0x47. status[2] = 0. Is this means that the DMA channel had lost its buffer?

           

          Besides, when dmachannel hasn't been initialized or had been destroyied, the CyU3PDmaChannelGetStatus() didn't get CY_U3P_DMA_NOT_CONFIGURED status code. sometimes the retune data is not on the list.

          • 2. Re: end point stop transmit data and cannot be reset
            abga

            Hi,

             

            Please use Uart Debug logs to check if there is any " Commit Buffer Error". If you are facing commit buffer errors then follow this KBA

            Invalid Sequence Error in Multi-Channel Commit Buffer - KBA218830

             

            Thanks & Regards

            Abhinav

            • 3. Re: end point stop transmit data and cannot be reset
              wu.zhijian_1557526

              Hi,

               

              I have checked the return value of the CommitBuffer, there is no any errors.

               

              Cause of using CyU3PDmaChannelGetStatus, I noticed that the difference between consXferCount and prodXferCount increasing. I think maybe the issue cause of the bandwidth of the ISOC is not enough. so I modified the DMA buffer size of the two UAC from 192 bytes to 384 bytes. and the other parameters about these.

              After two hours running, the difference between consXferCount and prodXferCount keeps in 0.

              Looks the issue has been fixed.