Hi all !!

I've been having trouble programming my controller for FIFO transfers..although i have successfully programed it for single transactions,FIFO doesn't seem to work for me.I started with the example AN66806 cypress gives.My interest is only for FIFO read.I read 128 bytes at the time from an FPGA and spit it out to the PC.

Keeping the signals from the FPGA  [REN=0 OE=0 RDY0=0] and trying to sent a 1 byte ( AA / 10101010 ) what i get is

03 05 AA 05 AA 05 AA 05 AA 05 AA.....  and so it goes on after giving 40 bytes it starts with 03 again and the same bytes appear.

If you google AN66806 you can have a look at the program,if you do, a have another question.At line 162 of the firmware GPIFTCB1 and GPIFTCB0  setup the transaction count.I change the value of these registers and nothing...the same value of bytes get transered (01F0)

The transaction count   is setup by TCXpire which i assume has something to do with registers GPIFTCB1 and GPIFTCB0 since i can't see anyware in the firmware program TCXpire.

Thank you everyone,any help will be very usefull

 TCXpire if used will be checked by the GPIF waveform to see whether it has to do more transaction.

With regards to 05 AA. Have you tried hardwiring the data bus (Say connect a few data pins to Vcc through pull-up or GND through pull-down) just to eliminate FPGA code being the reason behind the issue?

Regards,

Anand

 Thank you for the reply,i will try hardwiring the data pins tomorrow,nice idea..

About the TCxpire,i know it's role and that it is between state 2 and state 3 to arrange the status of the waveform ,whether to go to idle state or continue with the waveform. BUT i where do you change the value of TCXpire?? If i want to move 128 bytes or 256,i need to change the value of the counter TCxpire. and i can't see it in the firware of the program..

I will upload the firware and a picture of the waveform tomorrow

 What you said about the data pins getting efected by the FPGA firmware,you mean when the go to High Z state??When in both directions of the same bus try to make a pin high as a result insead of giving 3,3 v gives out a 2 v high Z signal. 

 Hello,

TCExpire is like  a flag/RDY signal, which when selected, is set when the GPIFTCB[3:0] register becomes zero. For every transfer of 1 Byte (in case of 8bit data bus)/ 2 Bytes (in case of 16bit data bus), GPIFTCB[3:0] is decremented. TCExpire option can be selected or de-selected in the GPIF Designer, as you design your GPIF waveforms. There is no need to access that in the firmware. Following is a briefing regarding the TCExpire, which I  believe you already know, but I am repeating it just in case for clarification:

In normal operation, oncce a GPIF transfer is triggered, it does not terminate until the Transaction Count (TC) has expired. The GPIF engine checks the state of the TC only when in IDLE state. While designing a GPIF waveform, you must have the waveform pass through an IDLE state in order for the GPIF to check the TC and finally terminate when TC has expired.

GPIF does allow you to save time and avoid going through the IDLE state by using the ‘Transaction Count Expired’ (TCxpire) signal. This TCxpire replaces RDY5, if GPIFREADYCFG.5 = 1. This is so as to enable reading the status of the transaction count in a DP (decision point) state. The EZ-USB sets the transaction-count expiration flag to ‘1’ when the transaction count expires. This feature allows the Transaction Counter to be used without passing through the Idle State after each transaction.

Thus, once TCExpire flag is selected using GPIF designer. Once waveforms are designed and imported, there is no need to worry about TCExpire anymore. As to change the count, you just need to change the no: of bytes to be transferred in GPIFTCB[3:0] registers and then trigger the GPIF transaction.

Regards,

Gayathri