DMA Callback executed at startup

GrSe_4664521 · ‎May 13, 2020

Hi,

I'm having trouble getting data from my sensor to my Windows application and I'm seeing that my multi-channel DMA callback is being executed when the board is powered up before anything has been sent over the GPIF port. I'm using AUTO_MANY_TO_ONE mode but I have a callback installed for debug printfs.

@StartApplication, running at SuperSpeedStarting Application

USB App Start Complete

USB LOG: 17

CyFxUsbGpifDmaCallback ENTERED type=0x8 w/ Buffer Length=49152

Sending OS Feature ID

Received a Class request

Sending CDC Config Data

Received a Class request

Setting CDC Configuration

Received a Class request

Sending CDC Config Data

My DMA buffers are 48k and there are two of them (1 for each of the 2 threads); when I had the configuration set for 2 buffers per thread I would see the callback executed 4 times. I'm following the Video_Class_UVC_Framework (AN75779) example with two producer sockets (threads on the GPIF) and one consumer socket (USB endpoint). When the application starts up I request 66k from the endpoint and I expect to see 48k and 18k buffers for each frame but I only see 48k buffers. Also, the first 96k of data that the application gets is always all zero, 96k is two 48k buffers and I suspect that data goes to the USB endpoint because of the first two callback executions when the application starts up. I know that my state machine must be wrong because things seem to fall apart after a handful of frames but I figured I needed to fix the initial callback executions first. Any assistance would be greatly appreciated.

<< Continuation of printf from above) >>

CyFxUsbGpifDmaCallback ENTERED type=0x8 w/ Buffer Length=49152

bReqType: 0x2 bType: 0x0 bTarget: 0x2 bRequest: 0x1 wValue: 0x0 wIndex: 0x86 wLength: 0x0

CyFxUsbHandleClearFeature: Resetting Imaging Endpoint...

CyFxBulkSrcSinkApplnUSBSetupCB: Resetting Imaging Endpoint...

CyFxUsbGpifDmaCallback ENTERED type=0x8 w/ Buffer Length=49152

bReqType: 0x2 bType: 0x0 bTarget: 0x2 bRequest: 0x1 wValue: 0x0 wIndex: 0x86 wLength: 0x0

CyFxUsbHandleClearFeature: Resetting Imaging Endpoint...

CyFxBulkSrcSinkApplnUSBSetupCB: Resetting Imaging Endpoint...

CyFxUsbGpifDmaCallback ENTERED type=0x8 w/ Buffer Length=49152

bReqType: 0x2 bType: 0x0 bTarget: 0x2 bRequest: 0x1 wValue: 0x0 wIndex: 0x86 wLength: 0x0

CyFxUsbHandleClearFeature: Resetting Imaging Endpoint...

CyFxBulkSrcSinkApplnUSBSetupCB: Resetting Imaging Endpoint...

CyFxUsbGpifDmaCallback ENTERED type=0x8 w/ Buffer Length=49152

bReqType: 0x2 bType: 0x0 bTarget: 0x2 bRequest: 0x1 wValue: 0x0 wIndex: 0x86 wLength: 0x0

CyFxUsbHandleClearFeature: Resetting Imaging Endpoint...

CyFxBulkSrcSinkApplnUSBSetupCB: Resetting Imaging Endpoint...

CyFxUsbGpifDmaCallback ENTERED type=0x8 w/ Buffer Length=49152

bReqType: 0x2 bType: 0x0 bTarget: 0x2 bRequest: 0x1 wValue: 0x0 wIndex: 0x86 wLength: 0x0

CyFxUsbHandleClearFeature: Resetting Imaging Endpoint...

CyFxBulkSrcSinkApplnUSBSetupCB: Resetting Imaging Endpoint...

CyFxUsbGpifDmaCallback ENTERED type=0x8 w/ Buffer Length=49152

bReqType: 0x2 bType: 0x0 bTarget: 0x2 bRequest: 0x1 wValue: 0x0 wIndex: 0x86 wLength: 0x0

CyFxUsbHandleClearFeature: Resetting Imaging Endpoint...

CyFxBulkSrcSinkApplnUSBSetupCB: Resetting Imaging Endpoint...

CyFxUsbGpifDmaCallback ENTERED type=0x8 w/ Buffer Length=49152

bReqType: 0x2 bType: 0x0 bTarget: 0x2 bRequest: 0x1 wValue: 0x0 wIndex: 0x86 wLength: 0x0

CyFxUsbHandleClearFeature: Resetting Imaging Endpoint...

CyFxBulkSrcSinkApplnUSBSetupCB: Resetting Imaging Endpoint...

GrSe_4664521 · ‎May 15, 2020

Problem turned out to be that I was checking for count hit in the wrong state.

View solution in original post

Hemanth · ‎May 14, 2020

Hi,

Data will be filled into the DMA buffer from PIB socket when 1) State machine is started in the firmware 2) IN_DATA action is performed in the state machine.

Please check these two points.

I guess you are not using UVC instead using your own custom application.

Regards,

Hemanth

GrSe_4664521 · ‎May 14, 2020

Hello,

Yes, my application is based on the multi-thread design of AN75779 but it is a custom design.

I have been able to eliminate the errant callback executions by pausing in the StartGPIF() function until my FPGA (the source of the GPIF data) has completed initialization (FPGA_DONE is a GPIO to the FX3). Things are improving, now I am seeing the following:

CyFxUsbGpifDmaCallback ENTERED type=0x8 w/ Buffer Length=49152

CyFxUsbGpifDmaCallback ENTERED type=0x8 w/ Buffer Length=18430

CyFxUsbGpifDmaCallback ENTERED type=0x8 w/ Buffer Length=0

My application is requesting 66k (67584) bytes and it is getting all of it except for 2 (49152+18430=67582). I added logging to the application and it seems that the first 2 bytes are missing. My GPIF port is 16 bits so seems like the first write is not being seen. I have the FPGA generating 16 bit values of increasing byte values (0x0100, 0x0302, 0x0504, etc.) and the first bytes in the application buffer are 0x02 and 0x03. Using ChipScope in the FPGA I see that the correct data (0x0100 and 0x0302) are written by the FPGA at the beginning of the frame. Is there anything in the state machine that might cause the first write to be missed?

GrSe_4664521 · ‎May 14, 2020

I have a commit on each thread in the state machine at the end of the frame so that no matter which thread was handling the last transfer it is committed. That seems to be working but any idea why I'm seeing the callback with a zero length DMA buffer? Is that normal? Since it is zero length does it matter?

GrSe_4664521 · ‎May 15, 2020

Problem turned out to be that I was checking for count hit in the wrong state.

Hemanth · ‎May 18, 2020

Greg Semeraro wrote:
I have a commit on each thread in the state machine at the end of the frame so that no matter which thread was handling the last transfer it is committed. That seems to be working but any idea why I'm seeing the callback with a zero length DMA buffer? Is that normal? Since it is zero length does it matter?

Good to know that you found the issue.

Just to mention:

When COMMIT action is performed in a state without INDATA action then any partial buffer on that thread will be wrapped up and along with that another buffer of zero length will be also be committed. So in case of Manual DMA channel you will be getting two DMA callbacks from that particular thread where COMMIT action is done - One with partial buffer content and another with zero size.

Regards,

Hemanth

DMA Callback executed at startup

Re: DMA Callback executed at startup

Re: DMA Callback executed at startup

Re: DMA Callback executed at startup

Re: DMA Callback executed at startup

Re: DMA Callback executed at startup

Re: DMA Callback executed at startup