- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi all,
I have test setup which consist of Zedboard and SuperSpeed Explorer Kit.
Zedboard with Xilinx Zynq700 FPGA sends test pattern through the parallel interface (CLK/FV/LV/DATA(7 bit)) to FX3 GPIF input
FX3 is connected to PC USB3 port and running example SW from AN75779.
i'm trying to capture video from UVC device "FX3" with VLC/Virtualdub.
Problem is that there are no incoming frames at all.
Here is UART output:
UsbEventCB: Detected SS USB Connection
USBSetupCB:In SET_FTR 0::1
USBSetupCB:In SET_FTR 0::1
USBSetupCB:In SET_FTR 0::1
USBSetupCB:In SET_FTR 0::1
USBSetupCB:In SET_FTR 0::1
UVC: Completed 0 frames and 0 buffers
UsbEventCB: SUSPEND encountered...
Entering USB Suspend [00]S‹VVHרUSBSetupCB:In SET_FTR 0::1
Leaving Suspend Mode
UVC: Completed 0 frames and 0 buffers
Application Started
UVC: Completed 0 frames and 0 buffers
UVC: Completed 20 frames and 56 buffers
UVC: Completed 42 frames and 45 buffers
UVC: Completed 64 frames and 35 buffers
UVC: Completed 86 frames and 24 buffers
UVC: Completed 108 frames and 13 buffers
UVC: Completed 130 frames and 3 buffers
UVC: Completed 151 frames and 51 buffers
UVC: Completed 173 frames and 40 buffers
UVC: Completed 195 frames and 29 buffers
UVC: Completed 217 frames and 19 buffers
UVC: Completed 239 frames and 8 buffers
UVC: Completed 261 frames and 0 buffers
UVC: Completed 282 frames and 46 buffers
UVC: Completed 304 frames and 35 buffers
UVC: Completed 326 frames and 24 buffers
UVC: Completed 348 frames and 14 buffers
UVC: Completed 370 frames and 3 buffers
UVC: Completed 391 frames and 51 buffers
So video is definitely received by FX3, but is not forwarded to PC.
I appreciate any help
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Media type GUID can be obtained from the below link:
Media Type Identifiers - Windows applications | Microsoft Docs
If you are using the source code of AN75779, then, the GUID would be that of YUY2 (Note that the order of bytes in the GUID given in the above link will be different from how it is mentioned in the descriptor. Please refer to unmodified AN75779 to figure it out)
In your case, 1280*720*2/(16384-16) ~ 112.609. So, if you capture the USB traffic from the FX3 to Host, you should be seeing 112 full MDA buffer sized packets and a partial packet for a frame. Note that the number 112 does not mean that you need to have 112 buffers in your DMA configuration. It means that for a frame, you will observe 112 packets of DMA buffer size in the USB trace (explained below).
USB trace - Using softwares like Wireshark, you will be able to capture the USB traffic between FX3 and Host from the time of enumeration. There are also Hardware analyzers, for example LeCroy USB Analyzer, which can do the same. Using either of these you can monitor the USB traffic.
Regards,
Hemanth
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Please refer to the below link and let me know if these are fine.
UVC Troubleshooting Guide – KBA226722
Regards,
Hemanth
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, Hemanth
That is an interesting guide, but I still don't see any frames on PC
So far I checked (and corrected) the following:
1. Set BPP to 8 (that's what goes out from FPGA)
GUID - have no idea how to check. It said it's YUV2 in comments. Is that enough?
2. Set correct frame width/height to 1280x720
Frame rate from FPGA is ~30.7 fps is that ok?
frame size for my case is 1280*720= 921600 bytes
3. by default frame size in glProbeCtrl is much greater then my case
4. DMA buffer size is 16*1024. That gives 1280*720/(16*1024-16) = 56.3. So I guess it's ok.
5. number of DMA buffers I need is 56. But Comment says that CY_FX_UVC_STREAM_BUF_COUNT defines number of buffers per thread
so how do I know how many threads DMA uses? is 4 per thread enough?
6. no debug prints in DMA CB
7. no error code 71
8. FV/LV are ok
9. PCLK from FPGA is 38 MHz
10. Have no idea if GPIF lines are terminated with 22-Ω. I use SuperSpeed Explorer Kit. I hope all required the termination is implemented
11. What is "USB trace"?
PS: as I mentioned above UART trace shows that number of sent frames is increasing. AFAIK that can only be possible if GPIF interface recognizes incoming stream and DMA successfuly passed data to USB3 output, Is that correct?
PPS: I also ran another UVC demo with CPU-produced image of cup. I works just fine
PPS2: cyfxuvcdscr.c has 2 descriptors with bit depth, both has 16 by default. When I change it to 8 only in CyFxUSBHSConfigDscr nothing happens. But when I change in CyFxUSBSSConfigDscr no more frames received: UVC: Completed 0 frames and 0 buffers
Could you please help me with questions in red?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Media type GUID can be obtained from the below link:
Media Type Identifiers - Windows applications | Microsoft Docs
If you are using the source code of AN75779, then, the GUID would be that of YUY2 (Note that the order of bytes in the GUID given in the above link will be different from how it is mentioned in the descriptor. Please refer to unmodified AN75779 to figure it out)
In your case, 1280*720*2/(16384-16) ~ 112.609. So, if you capture the USB traffic from the FX3 to Host, you should be seeing 112 full MDA buffer sized packets and a partial packet for a frame. Note that the number 112 does not mean that you need to have 112 buffers in your DMA configuration. It means that for a frame, you will observe 112 packets of DMA buffer size in the USB trace (explained below).
USB trace - Using softwares like Wireshark, you will be able to capture the USB traffic between FX3 and Host from the time of enumeration. There are also Hardware analyzers, for example LeCroy USB Analyzer, which can do the same. Using either of these you can monitor the USB traffic.
Regards,
Hemanth
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, Hemanth
I finally succeeded receive video on PC. To achieve it I just changed FPGA design to send 2560 byte per line (instead of 1280)
Rest of AN75779 design stays untouched
But now when I want to make use of wider GPIF bus (e.g. 16) it doesn't work again - blank screen
Here is what I do for 16-bit bus:
1) Changed bus width in GPIF designer
2) Changed state machine data/addr counters to (16*1024 - 16)/2 - 1 = 8183
Is that enough?
Is there any document that says how much data need to be sent to GPIF for 16/24/32-bit bus for specific resolution and how it should be organized?
Another very strange thing is when I change number of bits per pixel in "Class specific Uncompressed VS format descriptor" to something other than 16 it stops even to receive video:
UVC: Completed 0 frames and 0 buffers
How come descriptor value is related to incoming GPIF data?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Howmuch data the Host expects for one frame depends on the bits per pixel field mentioned in "Class specific Uncompressed VS format descriptor".
In your case the expected data for a frame is: 1280 * 720 * 2bytes = 1843200 Bytes - > which means 1280 * 2 bytes for a line.
The choice of the Bus width affects only the data/addr counters of GPIF.
So, now, for the same resolution/Bit depth (1280*720 / 2bytes), if you change the bus width from 8 to 16, the data/addr counters should be updated with 8183 as you did. And from FPGA you should drive 2 bytes for each clock edge and there should be 1280 clock edges for one LV.
Also make sure that your line data in bytes is a multiple of GPIF bus width in bytes. In your case, when the GPIF bus width is 2 bytes, 1280*2 bytes is a multiple of 2 bytes. So, that is fine.
Regards,
Hemanth
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes,
That's exactly what I have: LV is 1280 clocks, data counters are 8183, data bus is 16, descriptor says 16bpp. And yet I have blank screen
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It should work. Please share your GPIF project so that I can have a look. Do you get the debug prints - frames and buffers?
Regards,
Hemanth
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I finally got it work for 16-bit. Apparently pause between LV(line valid) was to short for 100Mhz PCLK. Strange thing that minimal requirements are not mentioned not in AN75779 user guider nor in FX3 TRM
Anyway I'm now switching to 32-bit/10bpp and have the same problems. I changed FSM counters to 4091 and line valid is now 640 clocks
I'm attaching my Cypress IDE project with GPID desiner project inside.
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Since your bpp is 10, your frame size is: 1280*720*10 bits = 1152000 bytes. You need to update this in the frame descriptor as well as probe control structure.
Now since the bus width is 4 bytes, I assume you are driving 4 bytes of image data for one PCLK. In that case, number of clock cycles for one line is - (1600 bytes)/4 = 400. Please let me know if you have any questions on this.
In the above calculation - 1600 is the size of line in bytes = (1280*10)/8
Regards,
Hemanth
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Thanks for idea, but still nothing:
UVC: Completed 0 frames and 0 buffers
DMA Reset Event: Frame timer overflow, time period = 200
Application Stopped
Application Started
UVC: Completed 0 frames and 0 buffers
DMA Reset Event: Frame timer overflow, time period = 200
Application Stopped
Application Started
DV is 400 clocks, pause between DV is 300 clocks. Clock freq is 100MHz:
BTW, comments say that descriptor and probe holds only maximum frame size so I might as well set it to 0xFFFFFFFF and forget. Moreover descriptor field is deprecated at all.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
1. How long is your frame blanking?
2. Are you not getting PROD events after you begin streaming?
Regards,
Hemanth
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
1. My frame blanking is calculated based on 30 FPS. Giving the total number of clock per frame is 3`333`333 and frame time 504000 I have approximately 2`829`333 clocks blanking. I guess it's long enough.
2. Yes, that's exactly the problem - FX3 unable even capture video stream. Strange thing that if I switch to 200 clocks per DV it starts to capture data (PROD events occur) but I still have black screen on PC
Regards,
Leonid
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Leonid,
Please use CyU3PGpifGetSMState() and check whether the state machine is running (after it is started). From the debug prints that you posted, it looks like frame timer got expired (which indicates that there is no callback for 200ms). This happens if there FV/LV/PCLK are not as expected.
Regards,
Hemanth
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Hemanth,
I added CyU3PGpifGetSMState right before debug output:
...
uint8_t curState = 0;
if (CyU3PGpifGetSMState(&curState) == CY_U3P_SUCCESS){
CyU3PDebugPrint (4, "Current SM state: %d\r\n", curState);
} else {
CyU3PDebugPrint (4, "CyU3PGpifGetSMState failed\r\n");
}
CyU3PDebugPrint (4, "UVC: Completed %d frames and %d buffers\r\n", glFrameCount, (glDmaDone != 0) ? (glDmaDone - 1) : 0);
...
And now I have this:
Leaving Suspend Mode
Current SM state: 0
UVC: Completed 0 frames and 0 buffers
Application Started
Current SM state: 2
UVC: Completed 0 frames and 0 buffers
DMA Reset Event: Frame timer overflow, time period = 200
Application Stopped
Application Started
Current SM state: 2
UVC: Completed 0 frames and 0 buffers
DMA Reset Event: Frame timer overflow, time period = 200
Application Stopped
Application Started
Current SM state: 2
UVC: Completed 0 frames and 0 buffers
DMA Reset Event: Frame timer overflow, time period = 200
Application Stopped
Application Started
Current SM state: 2
As you see SM stucked in WAIT_FOR_FRAME_START_0 regardless of FV. I checked with scope pins GPIO_29 (FV) and GPIO_28(DV) - they're fine
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Is there any way to arrange short online session? This problem remains unsolved for too much time
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Please do the below two tests:
1. Change the value assigned to glFrameTimerPeriod from CY_FX_UVC_FRAME_TIMER_VAL_200MS to CY_FX_UVC_FRAME_TIMER_VAL_1200MS.
2. If the PROD events still do not occur after doing the above change, then disable the timer and check. To do that you can undefine the macro FRAME_TIMER_ENABLE.
Regards,
Hemanth
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
The first one didn't help, and the second one gives the following:
Application Started
Current SM state: 1
UVC: Completed 0 frames and 0 buffers
Current SM state: 2
UVC: Completed 0 frames and 3 buffers
Current SM state: 5
UVC: Completed 0 frames and 3 buffers
Current SM state: 2
UVC: Completed 0 frames and 3 buffers
Current SM state: 5
UVC: Completed 0 frames and 3 buffers
Current SM state: 10
UVC: Completed 0 frames and 3 buffers
Current SM state: 2
UVC: Completed 0 frames and 3 buffers
Current SM state: 5
UVC: Completed 0 frames and 3 buffers
Current SM state: 2
UVC: Completed 0 frames and 3 buffers
...
and remains stucked with 3 buffers
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Since you are operating GPIF at 100MHz, you need to set setSysClk400 parameter of CyU3PSysClockConfig_t structure to CyTrue while calling CyU3PDeviceInit().
You can refer to cyfxbulksrcsink example in the below path to do the same:
$Install_Path$EZ-USB FX3 SDK\1.3\firmware\basic_examples\cyfxbulksrcsink
Please try the above and let me know the result.
Regards,
Hemanth
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Thanks! I guess we're getting closer - now DMA receives frames but fails to commit:
Application Started
Current SM state: 1
UVC: Completed 0 frames and 0 buffers
DMA Reset Event: Commit buffer failure
Application Stopped
Application Started
Current SM state: 2
UVC: Completed 0 frames and 0 buffers
DMA Reset Event: Commit buffer failure
Application Stopped
Application Started
Current SM state: 2
UVC: Completed 0 frames and 0 buffers
DMA Reset Event: Commit buffer failure
Application Stopped
Application Started
Current SM state: 2
I found that CyU3PDmaMultiChannelCommitBuffer returns CY_U3P_ERROR_INVALID_SEQUENCE.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Do you see PROD events coming now. I think yes, since you are getting commit buffer failure.
- To avoid commit buffer failure:
a. Increase DMA buffer size as much as possible.
b. Increase the Horizontal/Row active time.
(As you know,
Total Frame time(ft) = Frame Active time(fa) + Frame Blanking (fb)
Total Horizontal time (ht) = Line Active time(la) + Line Blanking time(lb)
Frame Active time(fa) = No. of lines * ht
Increase 'lb'. Doing so will increase 'fa'. Now, you have two options:
a. To maintain the same frame rate, you need to decrease 'fb' so that 'ft' remains constant.
b. If you change 'la' alone, then frame rate is compromised.
In both the above cases, ht is increased. This will decrease the rate of inflow to FX3 which will help commit buffer failure scenarios.)
Regards,
Hemanth
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I increased pause between DV and finally got an image. It's odd but at least I can it.
One thing still not clear - in future my aim is to send 120fps image. What would be the best values for CyU3PSysClockConfig_t structure?
Currently I have this:
CyU3PSysClockConfig_t clockConfig;
clockConfig.setSysClk400 = CyTrue;
clockConfig.cpuClkDiv = 2;
clockConfig.dmaClkDiv = 2;
clockConfig.mmioClkDiv = 2;
clockConfig.useStandbyClk = CyFalse;
clockConfig.clkSrc = CY_U3P_SYS_CLK;
Thanks a lot for support!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
clockConfig.setSysClk400 is the only parameter which needs to be taken care (to set it to True) when you operate GPIF clock at 100MHz.
Now what we have done by increasing 'lb' is decreasing the rate at which data is flowing into FX3. While designing you have to make sure that (Total line data in bytes) / (ht) is not exceeding USB 3.0 Speed and is less than that.
Regards,
Hemanth
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I see, thanks.
BTW, you mentioned previously that DV length for 10bpp case should be calculated as (1280*10/8)/4 = 400. But this gives me 3.2 images within one (in horizontal dimention), when received on PC:
Do you have and idea how to fix it?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It looks like you have configured the FPGA to send 400 pixel data in one line. Because, number of GPIF clocks 400 pixel data takes is
( 400 * 10 ) / 8 / 4 = 125. In this case number of lines you are actually sending now is 400 / 125 = 3.2
What I had mentioned earlier regarding the number 400 is: Your Line Valid should stay high for 400 clocks and you should send 1280 pixel data in this 400 clock cycles.
Please check that.
Regards,
Hemanth
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Right, thanks
Now I understand
Thanks a lot for support