KBA222479: USB2.0 Camera Interface Using FX2LP Question

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

cross mob
tostc_3976271
Level 1
Level 1

I'm trying to use USB2.0 Camera Interface Using FX2LP™ and Lattice CrossLink FPGA - KBA222479 firmware with a Lcsoft CY7C68013A Mini Board connected to my existing FPGA design. I have the firmware uploaded, and the board is recognized as a generic USB video device. I'm specifically only trying to stream data into the FX2LP. I'm trying to figure out:

1. Specifically, what are the minimal set of pins on the CY7C68013A board need to be connected to the FPGA?

2. Which pins are active high/low and how will each pin need to be driven?

FX2LP

PIN       A.K.A.           Description

PA0      INT0#           ??

PA1      INT1#           ??

PA2      SLOE           This is the enable signal for the FIFO's output driver.

PA3      WU2             ??

PA4      FIFOADR0   These signals select the active endpoint.

PA5      FIFOADR1   These signals select the active endpoint.

PA6      PKTEND      ??

CTL0    FLAGA       These flags are used by the FIFO to indicate status (Full, Empty,and Programmable)

CTL1    FLAGB       These flags are used by the FIFO to indicate status (Full, Empty,and Programmable)

CTL2    FLAGC       These flags are used by the FIFO to indicate status (Full, Empty,and Programmable)

PA7       FLAGD       FIFO Full flag output from FX2LP. Active low

??         Sync           (PC0  of  FX2LP) ????

RDY0    SLRD         SLRD pin should be asserted by the master to read data from the FIFO

RDY1    SLWR        SLWR pin should be asserted by the master to write data to the FIFO.

IFCLK   IFCLK         48Mhz clock to FX2LP

PB[0:7] FD[0:7]       Lower 8 bits of 16-bit data bus.

PD[0:7] FD[8:15]     Upper 8 bits of 16-bit data bus.

1. What is PA0/INT0 used for and is it  active high or active low?

2. What is PA1/INT1 used for and is it  active high or active low?

3. Is PA2/SLOE active high or active low?

4. Does FIFOADR[0:1] always need to be "10" for my scenario, or "11"? Is it for some reason active low?

5. When does PKTEND need to be asserted and is it active high or active low?

6. What specifically are FLAGA, FLAGB, FLAGC for, and are they active high or active low?

7. What pin is "Sync" on the FX2LP? Is it  active high or active low? ( Pin diagram on page 22 https://www.cypress.com/file/138911/download )

8. Can you confirm that SLRD and SLWR are active low?

I've already looked at these references:

USB2.0 Camera Interface Using FX2LP™ and Lattice CrossLink FPGA - KBA222479

https://www.cypress.com/documentation/application-notes/an61345-designing-ez-usb-fx2lp-slave-fifo-in...

https://www.cypress.com/file/44551/download

https://www.cypress.com/file/138911/download

http://blog.malcom.pl/wp-content/uploads/2015/02/CY7C68013A_schematic.png

Thanks

0 Likes
1 Solution

Hello,

- Keil uVision can be used to set breakpoints and view debug messages but it is supported only in the 100/128 pin package which has got the UART block. To view the code flow, you can toggle GPIO pins of FX2LP at appropriate places in the firmware.

- FX2LP firmware is configured to receive data from the slave FIFO interface in the AUTO mode. Apart from that, there is no involvement of the FX2LP CPU in the data path between the slave FIFO interface and the USB host. The image data that comes from the FPGA is received on the slave FIFO interface and is transferred to the USB host.

- FPGA has to check if there is free buffer space in the FX2LP before sending data to the FX2LP and should also keep track of the number of bytes of data sent. FX2LP is unaware of the headers or the number of bytes of data. It simply acts as a pass-through for the data received on the slave FIFO interface.

- The UVC driver drops the packets

1. If it does not find the proper header information

2. If the image frame size is not the same as mentioned in the Probe Control structure

- Please view the UVC 1.x spec for details on the 12byte UVC specific header. The error on the image in the host depends on which byte of the header is incorrect.

Debugging Steps:

A)

1. Disconnect FPGA from the FX2LP.

2. Assert SLWR#, FIFOADR[1:0] pins.

3. Modify the descriptor file such that it uses a vendor class and not the UVC class. Please refer to any of the DVK examples for vendor specific descriptors.

4. The device can now be detected in the Control Center. Check if the data transfer is successful in the Control Center

B)

1. Connect FPGA to FX2LP.

2. Use the vendor descriptors.

3. Check the FPGA code if it monitors the FX2LP FULL flag and asserts the SLWR#, FIFOADR[1:0]. (FIFOADR[1:0] can also be hard-wired if only one endpoint is used.

4. Now, check using the control center if data is received from the FPGA.

Best regards,

Srinath S

View solution in original post

0 Likes
9 Replies
SrinathS_16
Moderator
Moderator
Moderator
1000 replies posted 750 replies posted 500 replies posted

Hello,

- The polarities of SLOE, SLRD, SLWR, PKTEND, FLAGA, FLAGB, FLAGC can be set to either active HIGH or active LOW using the FIFOINPOLAR register. Please refer to section 15.5.8 of the EZ-USB TRM.

- PA0 and PA1 are not configured as interrupts. Also, PA0 is not used in the mentioned firmware. PA1 is used as GPIO pin and hence is does not have any active polarity.

- FIFOADR[1:0] pins are to be set according to the endpoint that is interfaced to the slave FIFO or the GPIF. Please refer to page 104 of the EZ-USB TRM.

- PC0 is used as the SYNC pin and is a GPIO configured as an output. This pin is driven HIGH to initiate communication from the FPGA.

Best regards,

Srinath S

0 Likes

Thanks for mentioning the EZ-USB TRM. I actually had no idea it existed.

1. I searched all over the FIFO-IN (slave FIFO) example C code and didn't see FIFOPINPOLAR being set. I just saw FIFOPINPOLAR mentioned in comments. What is the default value of FIFOPINPOLAR? Does that default value mean the pins are all active low or active high?

2. I don't see "PC0" or "SYNC" on any of the FX2LP pinout diagrams. (I linked to the CY7C68013A pin out diagrams in the first post). Is there another label for PC0/SYNC?

3. What is the difference between the 4 different FIFOs? Why are there 4 different FIFOs instead of one large one? The example FIFO-IN FPGA code sets FIFO ADDR to "10"  ( faddr <= "10"; ) which the manual says is the EP6 FIFO. Do you know why EP6 is selected?

0 Likes

Hello,

- The default values of the FIFOPINPOLAR register is such that the pins are active LOW.

- SYNC is just a name used in this particular example code example. The CY3684 DVK schematic uses the name PC0 for this pin. In the firmware attached with the document, ​the names PC.0 or SYNC is used. The register associated with driving this output pin is OEC.

- The advantage of having multiple FIFOs are as follows.

     -> Multiple endpoints can be used in parallel with separate FIFOs assigned to separate endpoints.

     -> Seamless transfer of data - One FIFO buffer can be filled with data while other FIFO buffer can be emptied simultaneously.

Any of the endpoints EP2, EP4, EP6 or EP8 can be selected.

Best regards,

Srinath S

0 Likes

USB2.0 Camera Interface Using FX2LP™ and Lattice CrossLink FPGA - KBA222479 is the ONLY example firmware I have found that actually results in the FX2LP showing up as a UVC webcam. While using an FPGA to drive the pins on the CY7C68013A, in every possible way I can think of, I can't get any actual images/frames to show up in webcam viewers like AMCap. I have also tried replacing the TD_init() code with the code from Auto Mode: Synchronous FIFO IN Data Transfers on page 118 but still, no webcam data is sent to the computer while viewing the "EZ-USB FX2 GPIF to Ext FIFO Example using Single Transactions" webcam using AMCap (or any other camera viewer).

1. How is this type of problem normally debugged?!! I need visibility into what the code is actually waiting for, or stuck on, while the "camera" (FX2LP) is being viewed by AMCap. Maybe the FX2LP is stuck in an infinite loop, waiting for some flag to become true. Who knows?!? 

Another thing that would be useful is to somehow program the CY7C68013A to always feed frames when being viewed by AMCap, no matter what. Ignore all flags and pins. Ignore whether the FIFO has data. Just send pixels of random values to the PC. I don't care if it looks like noise, as long as some kind of data is actually moving from the CY7C68013A to the PC. Then, I can start from there and program the CY7C68013A to read data from the FIFO if there is data on it, otherwise show noise.

2. How do I disable all things (like SLOE, PKT_END, SLWR, an empty FIFO, etc) that could possibly stop the CY7C68013A from sending pixels to the PC when the camera is being viewed by AMCap? After that, I can start to enable those things, one by one, until I find out the magical combination of signals that the mysterious CY7C68013A black box expects.

3. How do I pay someone to deal with this? The project should be really simple. Just have a normal, cheap FPGA, not some special dev kit, send 8 or 16 bits of VGA pixel data, at 48MHz, to a cheap, Lcsoft Mini Board (CY7C68013A) from eBay. Then, have the CY7C68013A show up as a generic webcam which immediately shows the pixel data from the FPGA when opened by any standard webcam viewer like AMCap. That's it. So simple, right? I would love to pay someone to do this. No cheating though. Not allowed to use any other FX2LP dev kit. Not allowed to use a FX3.

0 Likes

Hello,

- As an initial debugging step, disconnect FPGA from the FX2LP. Drive the SLWR# pin LOW. Connect the FIFOADR[1:0] pins according to the endpoint being used. Use the Cypress USB Control Center to read data. Depending on the default state of the FIFO data lines, the data gets displayed on the Cypress USB Control Center. This would ensure that the slave FIFO operation is fine.

- When using the FPGA connected to FX2LP, probe the flags, SLWR pins to see the behavior of the FPGA code. Share the same if possible.

- The FPGA verilog code should be such that the UVC class specific headers are added. The example code that comes with the document implements this.

- Use a USB protocol analyzer such as Teledyne LeCroy or software analyzers to view what is happening on the host-FX2LP interface.

Best regards,

Srinath S

0 Likes

- As an initial debugging step, disconnect FPGA from the FX2LP. Drive the SLWR# pin LOW. Connect the FIFOADR[1:0] pins according to the endpoint being used. Use the Cypress USB Control Center to read data. Depending on the default state of the FIFO data lines, the data gets displayed on the Cypress USB Control Center. This would ensure that the slave FIFO operation is fine.

A lot of detail is missing. Remember that my TD_init() code is the code from Auto Mode: Synchronous FIFO IN Data Transfers on page 118 and my TD_poll() code is an empty method. The endpoint, according to the code, seems to be EP8, which I'm assuming means FIFOADDR <= "11"; What is interesting is you imply that somehow, suddenly, SLRD, SLOE and PKT_END don't matter. That's surprising. Also, from the code, FIFOPINPOLAR = 0x00; making everything active low. So I'm assuming that means that SLWR needs to be 3.3v. You're implying that SLRD, SLOE and PKT_END and be any random combination of 3.3v or 0v and the FIFO will still function correctly. Is that really true?

Use the Cypress USB Control Center to read data.

How? The device isn't recognized in control center when it is acting as a USB webcam. Maybe you mean unplug the jumper, plug in the device, put the jumper back on, then use the device that shows up in control center. Even after that, it isn't clear as to what the next steps are to get control center to add data to the FIFO when the CY7C68013A FIFO is only listening for data on FD[0:15]. Is there some kind of always-present library code that makes the CY7C68013A always listen to the PC, in addition to listening to FD pins, for input data? That's surprising. Can you link to steps specifically for this FIFO IN use-case?

- The FPGA verilog code should be such that the UVC class specific headers are added. The example code that comes with the document implements this.

I didn't know that adding the headers was mandatory. Some Cypress example I read somewhere implied that it was optional. I read that the header is 12 bytes. The verilog code isn't very clear but the bytes seem to be

{6'b100011, buffer_eob_s1, buffer_header_bit_s1, 8'h0C};

time_stamp_captured[15:0]

time_stamp_captured[31:16]

FX3_DATA_BITS{1'b0}

The rest isn't clear... After the 12 byte header, 16368 bytes of image data need to be sent according to page 13. What would the FX2LP code need to look like so that all I have to do on the FPGA-side is provide IFCLK, VSYNC, and 8 or 16 bits of data on each clock cycle? Literally that is it. No SLWR, no SLRD, no PKT_END, no ADDR, no monitoring FLAGD or FLAGA. Nothing but IFCLK and FD[0:15] and some kind of VSYNC signal to keep the image aligned. Can that be done?

- Use a USB protocol analyzer such as Teledyne LeCroy or software analyzers to view what is happening on the host-FX2LP interface.

What is a USB sniffer going to do in this case?? It is just going to tell me that the CY7C68013A sent the usual camera descriptors when the device was plugged in, and then did nothing. Why did it do nothing after that? Because some mysterious, un-debuggable logic is waiting on who knows what before finally deciding to send pixel data to the PC. That is the real part that I need visibility into. I need to be able to add print() statements all over the place, or output a pin or LED high, to get some kind of indication of what the logic of the CY7C68013A is doing. How can I get a log or some sort of output to tell me what the CY7C68013A is doing internally?

0 Likes

Hello,

Apologies for not making it clear.

- When SLWR# is pulled LOW, it means that the slave FIFO is ready to sample data on FD pins. SLRD, SLOE matters only when FX2LP is sending data to the external interface. PKTEND is used only when there is a need for sending a short packet.

The initial debugging test that I mentioned was to have the SLWR# pin pulled LOW with the FX2LP is AUTO mode. The FX2LP would then sample data on the FD pins and commit it to the USB endpoint which can be read on the host application.

- Sorry for not completely mentioning the usage of Control Center.

As you have mentioned, the device is in UVC class and hence will not be detected in Control Center. So, please use the descriptors from the any of the FX2LP DVK examples that implement vendor class. Also, make sure that the endpoints that are configured in the *.c file match with the ones used in the descriptor file. Now, Control Center can access the device. This can be used to check if the FX2LP slave FIFO is in proper configuration.

- For UVC class, headers are mandatory. The 12 byte headers are to be added to every payload.

- When the data is only being sent from FPGA to FX2LP, SLRD, SLOE pins are not necessary. But, SLWR and PKTEND must be asserted by FPGA.

- The FLAG can be left unused if data integrity is not an issue. There can be chances that FX2LP buffers get overflowed with data and hence the new data that comes from the FPGA will be lost. The FLAG pins are used to know the status of FX2LP buffers before sending data to the FX2LP slave FIFO interface.

- FIFOADR[1:0] pins can either be driven by FPGA or can be hard-wired depending on the endpoint in use.

- UART based debug prints can be added to the FX2LP firmware (UART block is only available in 100-pin or 128-pin package of FX2LP). Please refer to the AN58009 on using FX2LP UART for print statements.

Best regards,

Srinath S

0 Likes

Here is the huge problem that is blocking me from making progress: There is no obvious way to see something as simple as the current logic state of the code running on the 56-pin CY7C68013A. A person either accidentally got lucky, and their FPGA logic and CY7C68013A logic are just right, or they much more likely were unlucky, and there is some mysterious issue somewhere. Since there is no visibility into the CY7C68013A, there is no way to get the detail needed to know where the bug is. That's a huge problem. Whether you are synthesizing a design on an FPGA, or writing code for a board with an embedded processor, you still have a way, using the unused pins, to get some kind of feedback as to why the design is not functioning correctly.

1. Is there at least some kind of CY7C68013A simulator that allows me to add break points and simulate the assertion of different CY7C68013A pins? Why isn't there a way to debug this thing in detail?

The initial debugging test that I mentioned was to have the SLWR# pin pulled LOW with the FX2LP is AUTO mode. The FX2LP would then sample data on the FD pins and commit it to the USB endpoint which can be read on the host application.

2. What is the exact FX2LP code to use for this experiment, and the exact, procedural steps that need to be performed in control center?

3. How would I know if there was something wrong with the 12 byte header I was sending to the CY7C68013A, or if I wasn't sending exactly 16368 bytes of image data before sending the 12 byte header again? Does the CY7C68013A blindly send the data to the PC in X byte chunks, regardless, or does it drop the data coming in from the FPGA if it doesn't meet some requirement?

4. If the PC connected to the UVC camera, running AMCap receives slightly incorrect packets, does it just drop them? In what specific situations does the PC drop those packets?

5. How can I detect different issues with the 12 byte packet? Will the image just completely not show up in a webcam viewer if the 12 byte packet is just slightly wrong?

6. I have an FX3 dev kit laying around but don't want to use it because it will make the unit cost of the product I'm developing cost too much. Is there a way that the FX3 could be used as a first step to get the much, much cheaper 56-pin CY7C68013A working as a UVC device?

0 Likes

Hello,

- Keil uVision can be used to set breakpoints and view debug messages but it is supported only in the 100/128 pin package which has got the UART block. To view the code flow, you can toggle GPIO pins of FX2LP at appropriate places in the firmware.

- FX2LP firmware is configured to receive data from the slave FIFO interface in the AUTO mode. Apart from that, there is no involvement of the FX2LP CPU in the data path between the slave FIFO interface and the USB host. The image data that comes from the FPGA is received on the slave FIFO interface and is transferred to the USB host.

- FPGA has to check if there is free buffer space in the FX2LP before sending data to the FX2LP and should also keep track of the number of bytes of data sent. FX2LP is unaware of the headers or the number of bytes of data. It simply acts as a pass-through for the data received on the slave FIFO interface.

- The UVC driver drops the packets

1. If it does not find the proper header information

2. If the image frame size is not the same as mentioned in the Probe Control structure

- Please view the UVC 1.x spec for details on the 12byte UVC specific header. The error on the image in the host depends on which byte of the header is incorrect.

Debugging Steps:

A)

1. Disconnect FPGA from the FX2LP.

2. Assert SLWR#, FIFOADR[1:0] pins.

3. Modify the descriptor file such that it uses a vendor class and not the UVC class. Please refer to any of the DVK examples for vendor specific descriptors.

4. The device can now be detected in the Control Center. Check if the data transfer is successful in the Control Center

B)

1. Connect FPGA to FX2LP.

2. Use the vendor descriptors.

3. Check the FPGA code if it monitors the FX2LP FULL flag and asserts the SLWR#, FIFOADR[1:0]. (FIFOADR[1:0] can also be hard-wired if only one endpoint is used.

4. Now, check using the control center if data is received from the FPGA.

Best regards,

Srinath S

0 Likes