I have a similar issue, but with our own monochrome camera (see "FX3 with AN75779 GPIF state machine").
Should you find a resolution I would be interested (I get good data to PC, but all camera applications just show a black screen).
You need to obtain register configuration settings for MT9V034 sensor from ON semiconductor and modify the sensor.c and sensor.h files of AN75779 example project, to stream monochrome data.
For streaming monochrome data, you can do the following:
1. Configure GPIF for 16-bit bus width by selecting 16 Bit in the Data bus width field of Interface Definition tab of GPIF II Designer.
2. Update the Counter limit value for LD_DATA_COUNT and LD_ADDR_COUNT to 8183, since the GPIF bus width is changed to 16 bits.
3. Rebuild the GPIF project after making the above mentioned changes.
4. Wire the Most significant 8 bits i.e. D[15:8] to 0x80 and connect the Least significant 8 bits i.e. D[7:0] to sensor output. Now, the 8-bit monochrome data from the sensor will be sent as a 'Y' value and 0x80 will be sent instead of 'U' or 'V' value.
VID and PID are listed under CyFxUSBDeviceDscr[ ] and CyFxUSBDeviceDscrSS[ ] in cyfxuvcdscr.c file.
'FX3' label is reported under CyFxUSBProductDscr[ ] in cyfxuvcdscr.c file.
Brandon & Raghuram,
Sorry to hijack this thread, but I'm having the same issues. However, I'm sending 8-bit YUY2 data, so have the 0x80 data already built in to the data stream. I get the correct data header and packets on the PC, but I still get a black screen with AMCap.
Further information in that using CamDiag64 (from AMcap) it looks like my modified AN75779 code thinks that I have a MPEG hardware encoder (and so does the original .img file that comes with AN75779). It states that it is unable to set the video format and frame rate. I have attached the report that CamDiag64 produces to assist in the diagnostics. I have tried swapping the YU bytes around, but that still doesn't produce an image. I have tried your USBVideoClassBulk example and that works fine (albeit using a single DMA commit buffer routine rather than the Multi DMA usd by 75779 (also this send s MJPEG data rather than YUY2). The data received by the PC appears to be correct (the header is 0C 8x 00 00 ... 00 where x is either C then E then D then F - EOF and New frame).
Thanks in anticipation.
CamDiag64-1.txt.zip 3.3 K
Thank you all for the help, this is valuable information!
Shaun, Raghuram, Thank you!
I'm wondering if part of the problem is that UVC requires certain resolutions. In other words it's doesn't support 752x480 that the MT9V034 image sensor is. So it's clocking more pixels per row and throwing off the state machine and the dma transfer to the PC side. I'm going to try either windowing the image sensor down to support 640x480, or going to a higher resolution and padding data to support the higher resolution. It will take me a day or two as my time is limited this week, I'll let you know what I find.(unless someone else can confirm or try it before I get to it)
Thanks again for for all the help!!
Can you think of another way to add the 0x80 to the upper byte(D8-D15)? I already have a board completed and I can't wire it that way. Is there away in the State machine to have a constant value of 0x80 in the upper byte. I was trying to do it in the DMA callback, but it seems too slow to do it there. I believe that I'm missing data from the camera sensor by changing it there.
Any help would be greatly appreciated!
Brandon, Can you modify your FPGA code to insert teh extra 0x80 code bytes. You will need to double your output clock to compensate for it and also your UVC headers for twice as much data. This is how we do it (although we send odd frames then even frame rather than a progressive output - so we get flicker).
This saves re-wring the PCB
Thank you for the suggestion! Unfortunately we didn't use an FPGA on this project. I've decided to move away from UVC and capture the RAW data on the PC side. Then, manipulate it and display. So far I've got it transferring but still fine tuning.
Thanks a ton, good luck on your project!!