1. Home
  2. Embedded Programming
  3. Cypress FX2 slave FIFO issue

Cypress FX2 slave FIFO issue

Hi all,

I am trying to temporarily disable my EP6 slave FIFO which is set to auto-in during data stream, and I am running into trouble no matter which approach I take. A little background: I'm grabbing data from a camera whose Line Valid (LV) signal clearly indicates when there is valid data, since it's only active when Frame Valid (FV) is also active. So, my current approach is to directly connect LV to the SLWR pin, and set SLWR polarity to active high.

If I forget about synchronizing the frame, I can acquire a whole image from the camera, but the data overlaps from one frame to the next, and the image is broken up cleanly into four sections, unless I happen to luckily make the image request at exactly the right time.

To synchronize to the frame, I would like to poll to see when FV has gone from low to high (it's active high) using a simple input pin. So the idea is to ignore all data until a request has come in and the next frame starts. I have tried two ways.

Approach 1: Normally leave EP6FIFOCFG set to 0x00, and change it temporarily to

0x0C (enable AUTO IN) on command. This doesn't seem to play nicely at all, I don't get any data out when I do this. I think you're not supposed to change this after setting it once, for some reason? The documentation doesn't really say much about that though. Alternately I tried changing the VALID bit of EP6CFG, but that also did not seem to work at all. Once again, I think you're supposed to set that and leave it.

Approach 2: Leave E6 FIFO set to AUTO IN all the time, and enable the SLCS which is controlled by a free IO port on the FX2. This doesn't seem to work either; I think it messes with EP2 which I use as an OUT endpoint but with AUTO OUT off so I can just check the input data in my firmware.

I could externally AND the SLWR signal with an I/O port pin that I control myself, but that's not the cleanest solution. Is there something else I can do in software to make this work?

Cheers,

Steve

Reply to
GrizzlySteve
Loading thread data ...

You could do an all software, have your firmware always transfer the data from the FIFO to the USB bus. This way you can ignore (remove from FIFO but do not send to USB) the data you do not want. The downside, this approach will be slower.

And don't forget that if the FIFO has less than the fifo size it will not be auto committed, it will need a PKTEND. You need a way to flush the last little bit that might be in the FIFO. Otherwise you will have residue data when the FV is active.

Best of luck, .chris

Reply to
Christopher Felton

m

Chris,

Thanks for the suggestion. Are you implying that I move each data byte with the CPU, or just check to see when there is enough data and arm the endpoint manually?

As for the PKTEND thing, the camera is configured to 2048 pixels per line, which is a multiple of 512, so in theory if I could just disable the endpoint FIFO during the time that I don't want to transfer data, it would work out just perfectly.

Steve

Reply to
S Battazzo

Alright, I've found a solution that seems to have worked! This is a bit of a kludge, which is perfectly OK since this is basically a one-off thing so I can do testing and calibration on my desk without needing an FPGA frame grabber (which admittedly would have been easier to handle synchronization with).

At any rate, I was previously running with both FIFOADR 1 and 0 tied high and low respectively, fixing the input to EP6. This time I took PA1 and wired it up to FIFOADR0. It occurred to me that I'm not using EP8 for anything at all, so the trick is to select EP8 by setting PA1 high to effectively deselect EP6 until the next Frame Valid low-to-high transition after a frame is requested. Works like a charm! I'm really not sure why this should work better than using SLCS, unless SLCS prevents the chip from receiving data from the host PC on an OUT endpoint which isn't even hooked up to the AUTO OUT on the slave fifo interface. The TRM is a bit unclear about that, but I guess that must have been the problem.

Steve

Reply to
GrizzlySteve

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.