7 Replies Latest reply on Sep 15, 2011 7:22 AM by dennis.mcleod

    external fifo


      I am totally confused about REVCTL and AUTOOUT. I have an FX2LP with a CPLD connected to the external fifo pins. The CPLD does nothing right now, but will soon read from EP2 and write to EP6. In the mean time, I'm trying to figure out the FX2LP side's configuration. I have it set for the following:  EP2 = valid, bulk, out, 512 x2.  EP4 = valid, bulk, out, 512 x2.  EP6 = valid, bulk, IN, 512 x2. EP8 valid, bulk, IN, 512 x2.


      My host is doing the following sequence: 


      1) usb_control_msg a vendorcmd (see case 0xBF in vendorcmd handler in attached bwtkusb.c) that reads 10 bytes. These 10 bytes are EP2FIFOFLGS, EP6FIFOFLGS, EP2FIFOBCH, EP2FIFOBCL, EP2468STAT, EP2CS, EP2FIFOBUF[0], EP2FIFOBUF[1], EP2FIFOBUF[2] and EP2FIFOBUF[3]


      2) usb_bulk_write of 4 bytes to EP2


      3) repeat step one, to compare all the flags and data.


      I started by using the bulkloop firmware as an example. Now, after reading through the EZ-USB TRM thoroughly I have modified the firmware to set it up for external fifo. The problem is that as soon as I try to follow the recommendation in the TRM to set REVCTL[1:0] to 11b, and set EP2's AUTOOUT=1, then trying to write to that endpoint from the host results in a timeout. I tried setting OUTPKTEND=0x82 also, but does not affect anything. I also tried doing a FIFORESET=0x80; FIFORESET=2; FIFORESET=0;   prior to the OUTPKTEND=1 line, but that doesn't help either.


      The ONLY configuration I can use that allows me to send data to the endpoint is 1) REVCTL[1:0] = 00b, EP2FIFOCFG.AUTOOUT=0  or 2) REVCTL[1:0]=01b, EP2FIFOCFG.AUTOOUT=0.  In either case, I can SEE the data I sent in EP2FIFOBUF[0]...EP2FIFOBUF[3].. and EP2's Empty flag is no longer set. However, EP2FIFOFLGS are report that the fifo is empty.


      Unless I've misunderstood the TRM, then I believe what I want is to have REVCTL=3, EP2FIFOCFG.AUTOOUT=1, and that this means I may have to "prime the pump" (as stated in TRM) by "initially arming the endpoints (OUTPKTEND w/SKIP=1 to pass packets to host)."  Which is baffling in and of itself.. OUTPKTEND is for "OUT".. what does that have to do with "passing packets TO HOST"???????


      While its true that nothing is sucking data out of the fifo yet, after i send 4 bytes from the host (which i can't even do) to EP2, I should see EP2FIFOBCL=4, EP2FIFOFLGS=NOTEMPTY,... but instead i see EP2FIFOBCL=0, EP2FIFOFLGS=EMPTY, EP2CS.EMPTY=0, EP2BCL=2. I want to simply send 4 bytes from the host and have it IMMEDIATELY available on the fifo pins with no interaction from the 8051. This shouldn't be that difficult to accomplish, but I'm getting meeting nothing but frustration. Anyone know what is going on here?


      The only change I made to fw.c was in main(), just before the call to TD_Init(). I put this:  REVCTL=0x03;




      thank you for any help! 

        • 1. Re: external fifo

          ugh. Apologies for so many typos. Here are two corrections to my post: 


          "prior to the OUTPKTEND=0x82 line, but that doesn't help either."


          "but instead i see EP2FIFOBCL=0, EP2FIFOFLGS=EMPTY, EP2CS.EMPTY=0, EP2BCL=4"

          • 2. Re: external fifo



            Did you provide the clock from CPLD? Since you have set the external clock option in the IFCONFIG register. Please try out the code attached, which I tried with Internal clock and it works.




            Now regarding your doubts:


            OUTPKTEND register: When ENH_PKT (REVCTL.0) is set to ‘1’, setting the skip bit of OUTPKTEND register to a ‘1’ causes the OUT packet to be skipped. It has nothing to do with passing packets to host.


            Now, why that you are seeing a change in value in EP2468STAT register and not EP24FIFOFLGS register: 


            The difference between EPxxFIFOFLGS and EP2468STAT is the domain in which data is present. EPxxFIFOFLGS register will give the status of the Flags (EF, FF and PF) when data is in the peripheral domain (fifo). Once the data has been committed from the peripheral domain (fifo) to the USB domain (Endpoint) the status of the same Flags will be given by EP2468STAT register. So we need to refer EP2468STAT register when the data is present in the USB domain (endpoint) and EPxFIFOFLGS/ EPxxFIFOFLGS registers when the data is in the peripheral domain (fifo).




            In your case, since you had kept the AUTOOUT = 0, it is in manual mode. Thus after you send data bytes to EP2, unless you comit the data it will be there in USB domain. Thus the flags of EP2468STAT will reflect the change, and EP24FIFOFLGS won't. But once in AUTO mode (AUTOOUT =1 ), EP24FIFOFLGS will reflect the change in status of Flags as the packets are auto committed.


            Similarly EP2BCH/L reflect the  Byte counts when packets are in USB domain.


            EP2FIFOBCH/L reflect the byte counts when the packets are in peripheral domain. That is why when in Manual mode (AUTOOUT - 0) only EP2BCH:L becomes = 0x02:00.







            • 3. Re: external fifo

              Thank you very much for your help. I also stumbled onto this page http://www.cypress.com/?id=4&rID=32643 which indicated that the order in which i was performining initialization was not correct.


              In the code I attached to the original post, I do see that I had AUTOOUT=0 .. but that was because that was the only way I could get data to flow. Though I did many times try various configurations with AUTOOUT=1 and REVCTL.1=1.


              I am definitely seeing better results now, but the one remaining problem is that although EP2FIFOBCL=4 (the correct value), the data in EP2FIFOBUF[0] .. EP2FIFOBUF[3] is garbage. I have the programmable flag set to assert whenever there is 4 (or more) bytes in EP2FIFOBUF.


              I will review your code and try your suggestions asap. Thank you! 


              Here's the current state of things as reported by my host application.. both before and after transferring 4 bytes (0x01, 0x02, 0x03, 0x04) to EP2: 


              read 12 bytes from EP0.. 12
              write 4 bytes to EP2.. 4
              read 12 bytes from EP0.. 12
              EP2FIFOFLGS = 0x2, EMPTY
              EP6FIFOFLGS = 0x2, EMPTY
              EP2FIFOBCH = 00
              EP2FIFOBCL = 00
              EP2468STAT = 0x59, EP2E, EP4F, EP6E, EP8E
              EP2CS = 0x4, EMPTY
              EP2FIFOBUF[0] = 0xc1
              EP2FIFOBUF[1] = 0x2
              EP2FIFOBUF[2] = 0xc1
              EP2FIFOBUF[3] = 0x2
              EP2BCH = 0xa8
              EP2BCL = 0x7e
              EP2FIFOFLGS = 0x4, PROGFL
              EP6FIFOFLGS = 0x2, EMPTY
              EP2FIFOBCH = 00
              EP2FIFOBCL = 0x4
              EP2468STAT = 0x58, EP4F, EP6E, EP8E
              EP2CS = 0x10, NPAK0
              EP2FIFOBUF[0] = 0x28
              EP2FIFOBUF[1] = 0xf8
              EP2FIFOBUF[2] = 0x28
              EP2FIFOBUF[3] = 0xf8
              EP2BCH = 0x3c
              EP2BCL = 0xd9

              RAW DATA:
                BEFORE: 02 02 00 00 59 04 c1 02 c1 02 a8 7e
                AFTER: 04 02 00 04 58 10 28 f8 28 f8 3c d9

              As you can see, the FIFO flags and bytecounts are now correct, but the rubbish in EP2FIFOBUF i don't understand.

              • 4. Re: external fifo

                I meant to attach the most recent revision of my firmware.. here it is.

                • 5. Re: external fifo





                  Since you have set FX2LP to work in Auto mode, there is no way you can intervene and read the values from the buffers using 8051. Thus the data bytes read using EP2 is expected to show incorrect values. Please try reading from your CPLD and you should be getting the correct data bytes.







                  • 6. Re: external fifo





                    Sorry.. correction in my previous response..




                    "Thus the data bytes read from EP2 usin Vendor command is expected to show incorrect values"







                    • 7. Re: external fifo

                      Exactly the response I hoped for :)  Thank you very much for all your help!  CPLD will be ready sometime today.