Some problem on the CyFxUvcApplnDmaCallback()

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
rossihwang
Level 3
Level 3
5 questions asked 50 sign-ins 25 replies posted

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

0 Likes
1 Solution

Hello,

We suggest configuring FX3's GPIF first and then starting the sensor as done by AN75779 firmware.

Please  follow the same initialization sequence as in AN75779

Regards,
Rashi

View solution in original post

0 Likes
27 Replies
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hello Rossi,

Is it possible to share the firmware with us for review?

Also, please use the API CyU3PGpifGetSMState () inside the infinite for loop to check the state of the state machine. Print these states along with the UART debug logs and share the complete logs for us to understand the problem better.

Best Regards,
Jayakrishna
0 Likes

Hi Jayakrishna

 

1. Could you provide me an email? I would send the firmware to you privately.

2. I've called CyU3PGpifGetSMState(). It shows that the state is rolling(may not in proper sequence)

 

Regards

Rossi

0 Likes

Hello Rossi,

Please confirm if you are not calling CyU3PDebugPrint the CyFxUvcApplnDmaCallback

 

Regards,
Rashi
0 Likes

of course not, as far as I know, this will stuck the callback

Regards

Rossi

0 Likes

Hello,

I understand that you are using the AN75779 state machine for your application. Is my understanding correct? If yes, are there any modifications done to the default state machine. If there are no changes done, please share the PCLK, FV and LV traces.

If some modifications are done, please let us know the details

Regards,
Rashi
0 Likes

Hi

1. Yes, It's the same state machine as AN75779

2. I've validated the DVP signals as well. FV and LV are below, PCLK is around 48MHz

fv.jpglv.jpg

3. Please note that the current problem is stability. As I mentioned above,  sometimes it boots with USB detected but no frames shown, a reset(map up to five times as we test) on 3014 may recover this situation. If we can rule out the problem of firmware, I just wonder whether there are any rules I missed in my hardware design that may cause this problem. 

Regards

Rossi

0 Likes

Hello Rossi,

While going through the firmware files shared, I noticed that zero-length buffers (ZLP) are handled using the EMPTY_BUFFER_RESET macro. IS my understanding correct?

If yes, I didn't see tracking of ZLP in the DMA callback. I could just see the variable is incremented when partial buffer is seen. How is the buffer count checked in the firmware.

Please try checking buffer.count for partially filled buffers. You can use global variable to store dmaBuffer.count when the buffer received is partially filled and then print the variable in for loop (for(;;)) of thread entry fucntion.

Also, please let me know if you are using Isochronous endpoints or BULK endpoints for video streaming.

3. Please note that the current problem is stability. As I mentioned above,  sometimes it boots with USB detected but no frames shown, a reset(map up to five times as we test) on 3014 may recover this situation. If we can rule out the problem of firmware, I just wonder whether there are any rules I missed in my hardware design that may cause this problem.

>> Can you please share the UART debug prints when the above issue is seen. 

 

Regards,
Rashi
0 Likes

Hi

1. EMPTY_BUFFER_RESET is a kind of workaround I currently use to handle this problem. The method works as when the consecutive glDmaDone <= 1 condition is detected, it will call the CyU3PDeviceReset. Please search the keyword "glDmaDoneCount" for the full implementation.

2. I don't have UART debug log on hand. But it is something like a bunch of "

UVC: Completed [non-zero] frames and [zero or one] buffers

", when enable the DEBUG_PRINT_FRAME_COUNT macro

Regards

Rossi

0 Likes

Hello Rossi,

In the files shared, I could only see glDmaDoneCount incremented in UVCAppThread_Entry. I didn't see checking of ZLP. 

Can you check if ZLP is received in the DMA callback

if (dmaBuffer.count == CY_FX_UVC_BUF_FULL_SIZE)
{
/* A full buffer indicates there is more data to go in this video frame. */
.......
}
else
{

...

glDmaDoneCount = dmaBuffer.count;

}

And then check the if value of  glDmaDoneCount is zero when the partial buffer is received (when DEBUG_PRINT_FRAME_COUNT is enabled)

if (streamingStarted == CyTrue) {
if ((glDmaDone == 0) && (glDmaDoneCount == 0)

{

//reset the device
}

 I don't have UART debug log on hand. But it is something like a bunch of "

>> Is it possible to add two variables to track the number of Full DMA buffer and partially filled DMA buffer received and print the values in for (;;) loop

 

Regards,
Rashi
0 Likes

Hi

For the first suggestion, I did a similar test, printing out the sum of dmaBuffer.count every second. I'm sure that it's zero.

Regards

Rossi

0 Likes

Hello Rossi,

I understand that you are using a custom board for your application now.

Is it possible for you to test the firmware on CYUSB3KIT-003 (FX3 Explorer kit)? This will help us to narrow the down the issue to firmware/hardware

Regards,
Rashi
0 Likes

Hi

I actually did some tests on CYUSB3KIT-003 with our sensor board connecting via DuPont line. It works just fine

Regards

Rossi

0 Likes

Hello Rossi,

If the same firmware and the sensor is working with CYUSB3KIT-003 and not with a custom board. It seems there is some issue with the custom board. To confirm, please try programming GPIF to USB example on the custom board and check if the data is received on USB side

Regards,
Rashi
0 Likes

Hi Rashi,

Is it the example you mentioned called "gpiftousb", Need any software on the host during the test? 

 

Update: Should I test like the below image?  

rossihwang_0-1658129992441.png

 

Regards

Rossi

0 Likes

Hello,

Yes, please test the GPIF to USB data transfer using gpiftousb example of the SDK and you can use Cyusb_linux to receive the data from GPIF on the USB side.

Regards,
Rashi
0 Likes

Hi Rashi

I've successfully run the gpiotousb test! There is a difference between custom board and cyusb3kit

the received data of cyusb3kit is like

rossihwang_0-1658219038435.png

 

while on custom board is

rossihwang_1-1658219053920.png

Any ideas on this difference?

Regards

 Rossi 

 

0 Likes

Hi Rossi,

Please let me know if your custom board is similar to CYUSB3KIT-003. 

Can you ground/pull up  the GPIF bus and check if the received data is fine?

Regards,
Rashi
0 Likes

Hi Rashi

1. I can only say it is not totally the same

2. Some background on custom board first

GPIO[0-7] :8 bit data from sensor

GPIO[8-15]: GPIO15 with external pull up to emulate 16bit YUYV

GPIO16: PCLK

GPIO[27]: an unused IO

GPIO[28]: LV

GPIO[29]: FV

GPIO[30-31]: default boot from SPI flash, should be 0b1X

 

Some test results on custom board and cyusb3kit

On custom board

Ground GPIO[0-7],  GPIO16, GPIO[27-29], read 00 ff ff af

Pull up GPIO[0-7],  GPIO16, GPIO[27-29], read ff ff ff af

It shows the GPIO16,27,28, 29 are not in control, in addition, GPIO30 should be high for SPI boot, but in fact, it is low 

On cyusb3kit

Ground GPIO[0-7],  GPIO16, GPIO[27-29], read 00 00 00 00

Pull up GPIO[0-7],  GPIO16, GPIO[27-29], read ff 00 01 28

It shows that only the GPIO28 is not in control

 

I wonder that

1. Why GPIO28 of cyusb3kit doesn't respond to external input? Is there any drive capacity requirement?

2. There are a few IOs of the custom board are seems frozen, Could we draw some conclusions from this phenomenon?

3. And I found the gpiftousb demo only sample gpif once on startup, is it the right behavior?

Regards 

Rossi

0 Likes
rossihwang
Level 3
Level 3
5 questions asked 50 sign-ins 25 replies posted

Hi Rashi

As our problem can be recovered from a few resets, our hardware guy wonders is it related to the description below(From AN70707)

rossihwang_1-1658383267012.png

 

If this 1.2v supply is not been handled well, would the system reset to an unstable state in which GPIF reading nothing? Thanks

Regards

Rossi

 

 

0 Likes

Hello Rossi,

If this is the case, the device will reset and try to re-enumerate again. Please let me know if the device is a lost streamer when the data transfer is done.

Also, are you able to read expected data from GPIF after few resets?

Answering your questions below

Why GPIO28 of cyusb3kit doesn't respond to external input? Is there any drive capacity requirement?

>> The drive strength for every GPIOs are same by default

There are a few IOs of the custom board are seems frozen, Could we draw some conclusions from this phenomenon?

>> Please let me know if those GPIOS are initialized by firmware as input/output or are you using them for GPIF only

And I found the gpiftousb demo only sample gpif once on startup, is it the right behavior?

>> No, the GPIF bus will be sampled every time the DMA buffer is free.

Can you please share the Debug prints when the test is done with GPIF to USB. Please enable STREAMING_MANUAL and track the CY_U3P_DMA_CB_PROD_EVENT/ CY_U3P_DMA_CB_CONS_EVENT events. We suggest you to used global variable to track the events and print in the thread entry function instead of DMA callback

Regards,
Rashi
0 Likes

Hello Rashi

Thanks to your help, the gpiftousb works well both on custom board and cyusb3kit now, DQ[0:7] can respond to inputs. For the next step, should we further test PCLK, FV, and LV in a similar manner?

Regards

Rossi

 

0 Likes

Hello Rossi,

Yes, from the gpiftousb test it looks that there is no hardware issue on the GPIF side when the internal GPIF clock is used.

Please try the test with PCLK, FV,LV 

Regards,
Rashi
0 Likes

Hi Rashi

I did a further test on PCLK, FV, and LV. I mock these signals with FPGA, the output signals are almost with the same configuration as the sensor's output (30fps, 1280*720,pclk=50MHz).

The experiments go like this, first I start the DVP signal outputs, then connect the 3014 to the PC, and finally read the camera via Cheese(app on ubuntu). On the cyusb3kit, it works and can directly read full black images(GPIF samples many zeros as the gpiftousb experiment shown). However, on the custom board, the USB device is not been enumerated when ejecting the 3014 board. and we find out if start the DVP signals after the 3014 is enumerated, we can read images well(full white image). Do you have any suggestions on the results? Thanks

Regards

Rossi

0 Likes

Hello,

We suggest configuring FX3's GPIF first and then starting the sensor as done by AN75779 firmware.

Please  follow the same initialization sequence as in AN75779

Regards,
Rashi
0 Likes

Hi Rashi

What might happen, if it's in inverted order?

Regards

Rossi

0 Likes

Hello Rossi,

The GPIF master FPGA/sensor will start providing the clock PCLK /data before the GPIF  block is initialized.

We recommend that the PCLK should start after the GPIF is initialized, loaded and started. The same sequence is followed in AN75779 firmware.

Please let me know is there frame loss when you initialized the sensor before GPIF is initialized.

Regards,
Rashi
0 Likes

Hi Rashi

Thanks for your help. After some tests, the custom 3014 board works fine with the simulated DVP signals. We guess the problem may highly possibly be caused by the sensor board. Please close this thread. I will start a new thread if there are any new problems related to 3014. Thanks again.

Regards

Rossi 

0 Likes