We’ve got a realtime GPIF-based application, and we would really appreciate clarification on one point.
Does the flow state test the transaction counter? Our waveform deliberately never enters the IDLE state, and yet it is stopping anyways when the TCB reaches zero. How is this possible?
(We use the Programmable Flag to trigger the firmware to write a counter into EP2BUF[0-1] after they’ve been filled, so EP2GPIFPFSTOP is 0.)
My current workaround is to periodically set GPIFTCB3 to 0xff. I suppose I could alternatively turn off AUTOIN and have the firmware submit the buffers to EP2, but only if that can be done without stalling the GPIF for even a single IFCLK cycle.
Thank you for considering my question!
A flow state can be considered to be an extra layer on top of the normal decision point of the gpif. If you are loading GPIFTCB3:0 with the desired number of transactions, the GPIF will check the transaction count each time when it is in the Idle state.
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. For further information please refer to Section 10.4.3.2 on Page 150 in EZ USB TRM: https://www.cypress.com/file/126446/download
Thank you for taking the time to respond. However, it does not seem to me that you have addressed my question yet.
1. Our state machine does not ever enter Idle. Not through delay states, not through decision states.
2. Our state machine nevertheless stops when TCB reaches zero.
I have gone over and over the TRM. Why can a waveform stop without an abort or going to state 7? I don’t want it to stop.
>> Please provide a diagram of your gpif state machine or your gpif file.
>> How are you determining that the gpif is not going to IDLE state?