Reset FX2 EP2 IN FIFO buffer

Recently I am focusing on a project, which using CYPRESS fx2.

In fact, it is a very simple project, because the CYPRESS fx2 USB chip function and interface is very flexible, but I also come a puzzle.

The system is a data capture system.

FPGA send the realtime data to the FX2 by Slave mode.

FX2 configure the EP2 as quard buffer, each buffer 512B, and auto in, auto in length is 512B.

Data path from FPGA to FX2 then to PC is pass now, and it working now.

But I come a problem on how to reset the FX2 EP2 buffer.

For example, when PC application need 10M buffer, it will bulk in from EP2 for 10M data, when start bulk, it will ask FPGA start sending data to FX2, but when App receive 10M data, FPGA will still send 512*2 B data to FX2, but these 2K data will not fecth by Ap.

So the next time, PC start bulk in again, the 2K data of the last time will be the first part of the bulk in data.

So I make a vendor request interface, which will invoke the EP2 FIFO RESET function in firmware.

But this function does not take effect.

So does anyone familiar with how to reset(discard) the EP2 quard buffer data, so when I start bulk in again, the data in the EP2 quard buffer will not valid, only when the FPGA really sending the data to the FX2 for the second Bulk in.

Briefly , i want to implement the function.

EP2 is quard buffer, when the data in EP2 four buffer, and is valid.

By what method, I can discard the data in the EP2 in buffer, so the buffer is empty and could accept the data from FPGA.

I use the FX2 sample code, for EP buffer reset.

It is using

SYNCDELAY;
FIFORESET = 0x80;
SYNCDELAY;
FIFORESET = 0x02;
SYNCDELAY;
FIFORESET = 0x00;

But it does not work.

workingmailing@163.com wrote:


But I come a problem on how to reset the FX2 EP2 buffer.

For example, when PC application need 10M buffer, it will bulk in from EP2 for 10M data, when start bulk, it will ask FPGA start sending data to FX2, but when App receive 10M data, FPGA will still send 512*2 B data to FX2, but these 2K data will not fecth by Ap.

So the next time, PC start bulk in again, the 2K data of the last time will be the first part of the bulk in data.

So I make a vendor request interface, which will invoke the EP2 FIFO RESET function in firmware.

But this function does not take effect.

So does anyone familiar with how to reset(discard) the EP2 quard buffer data, so when I start bulk in again, the data in the EP2 quard buffer will not valid, only when the FPGA really sending the data to the FX2 for the second Bulk in.

The FIFORESET register works correctly. I use it in every FX2 project I
do. I can think of two possibilities. Either (1) your vendor command
is not being executed (do you have an LED you can blink to prove this?),
or (2) you have some additional buffering in your FPGA, and that’s where
the stale data is stored. We often have to have an “FPGA buffer reset”
vendor command as well as a “FIFO buffer reset”.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

thank you Tim.

Pls confirm that you are using the auto in EP2 with Length 512 and quard buffer.

I can confirm that the vendor command is executed.
And it is really the problem, only the first time after FX2 reset, because there is no data on the EP2 quard buffers, and the first time captured data is right. (Down load by EP6 frist, then read back)

For the second time, each time the data read from FPGA is header by the 2K data which is the last captured data last part.

FPGA is much more than 2k, this 2K is just the EP2 quard buffer.

Now i just change my APP.

First start FPGA.

Let FPGA insert data to FX2 ep2 in quard buffer, 2k.

turn off FPGA, so it will not insert data again.

Read 2k (discarded it)DATA FROM fx2, make the EP2 buffer empty.

Then start FPGA again, so the data from FX2 is the realtime data.

workingmailing@163.com wrote:

Pls confirm that you are using the auto in EP2 with Length 512 and quard buffer.

The word is “quad,” not “quard”.

I can confirm that the vendor command is executed.

How did you confirm that? I can assure you that the FIFORESET register
works as advertised. Either the command is not getting through, or
you’re filling the FIFO again after the reset.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

> -----Original Message-----

From: xxxxx@lists.osr.com [mailto:bounce-507860-
xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, July 10, 2012 10:28 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Reset FX2 EP2 IN FIFO buffer

workingmailing@163.com wrote:
> Pls confirm that you are using the auto in EP2 with Length 512 and
quard buffer.

The word is “quad,” not “quard”.

Possessing only a passing familiarity with the subject at hand (that’s actually a generous description, now that I think about it), I read that as “guard”. Is that a possible reading in this context?

> I can confirm that the vendor command is executed.

How did you confirm that? I can assure you that the FIFORESET register
works as advertised. Either the command is not getting through, or
you’re filling the FIFO again after the reset.

Phil Barila wrote:

> workingmailing@163.com wrote:
>> Pls confirm that you are using the auto in EP2 with Length 512 and quad buffer.
> The word is “quad,” not “quard”.
Possessing only a passing familiarity with the subject at hand (that’s actually a generous description, now that I think about it), I read that as “guard”. Is that a possible reading in this context?

Not in this particular case. The FX2 buffers are allocated in chunks of
512 bytes. A single endpoint can do single buffer (512), double buffer
(1024), or quad buffer (2048). It really is “quad”.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts

Not in this particular case. The FX2 buffers are allocated in chunks of
512 bytes. A single endpoint can do single buffer (512), double buffer
(1024), or quad buffer (2048). It really is “quad”.

Thanks!

thank you Tim.

About how to confirm the vendor request of Reset fifo is invoked.

Because one, I replace the code from
SYNCDELAY;
FIFORESET = 0x80;
SYNCDELAY;
FIFORESET = 0x02;
SYNCDELAY;
FIFORESET = 0x00;

to TD_init();

the device could not download code by EP6, before this replacing, it is ok.

It is definitely reset pipe before the second time invoke bulk in in my App.

On the other hand, the 2K header is always the last time I read 10M bytes, it is the 10M to 10M+2K part.

workingmailing@163.com wrote:

About how to confirm the vendor request of Reset fifo is invoked.

Because one, I replace the code from
SYNCDELAY;
FIFORESET = 0x80;
SYNCDELAY;
FIFORESET = 0x02;
SYNCDELAY;
FIFORESET = 0x00;

to TD_init();

the device could not download code by EP6, before this replacing, it is ok.

I’m sorry, I can’t tell what this means. Could you post your FX2 code,
or perhaps email it to me?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Time, it is the code,

case VR_FIFO_RST is for reset EP2 quad IN buffer

BOOL DR_VendorCmnd(void)
{
WORD addr, len, bc;
WORD ChipRev;
WORD i;
BOOL IICRet;
// BYTE cypressReg;

// Determine I2C boot eeprom device address; addr = 0x0 for 8 bit addr eeproms (24LC00)
I2C_Addr = SERIAL_ADDR | ((I2CS & 0x10) >> 4); // addr=0x01 for 16 bit addr eeprom (LC65)
// Indicate if it is a dual byte address part
DB_Addr = (BOOL)(I2C_Addr & 0x01); //TPM: ID1 is 16 bit addr bit - set by rocker sw or jumper

switch(SETUPDAT[1])
{ //TPM handle new commands
case VR_GETI2C_TYPE:
*EP0BUF = DB_Addr;
EP0BCH = 0;
EP0BCL = 1; // Arm endpoint with # bytes to transfer
EP0CS |= bmHSNAK; // Acknowledge handshake phase of device request
break;
case VR_GET_CHIP_REV:
ChipRev = GET_CHIP_REV();
*EP0BUF = ChipRev;
EP0BCH = 0;
EP0BCL = 1; // Arm endpoint with # bytes to transfer
EP0CS |= bmHSNAK; // Acknowledge handshake phase of device request
break;
case VR_TEST_MEM:
*EP0BUF = 0x0F; // Fail
EP0BCH = 0;
EP0BCL = 1; // Arm endpoint with # bytes to transfer
EP0CS |= bmHSNAK; // Acknowledge handshake phase of device request
break;
case VR_SETI2CADDR:
I2C_Addr = SETUPDAT[2];
break;
case VR_I2C_100:
I2CTL &= ~bm400KHZ;
EP0BCH = 0;
EP0BCL = 0;
break;
case VR_I2C_400:
I2CTL |= bm400KHZ;
EP0BCH = 0;
EP0BCL = 0;
break;
case VR_RENUM:
*EP0BUF = 7;
EP0BCH = 0;
EP0BCL = 1; // Arm endpoint with # bytes to transfer
EP0CS |= bmHSNAK; // Acknowledge handshake phase of device request
EZUSB_Delay(1000);
EZUSB_Discon(TRUE); // renumerate until setup received
break;
case VR_NOSDPAUTO:
// we want specify our own length for the transfer so
// disable the automatic length feature of the Setup Data Autopointer
SUDPTRCTL &= ~bmSDPAUTO;

EP0BCH = SETUPDAT[7];
EP0BCL = SETUPDAT[6];
SUDPTRH = SETUPDAT[3];
SUDPTRL = SETUPDAT[2];
break;

case VR_FIFO_RST:

SYNCDELAY;
FIFORESET = 0x80;
SYNCDELAY;
FIFORESET = 0x02;
SYNCDELAY;
FIFORESET = 0x00;

break;

default:
return(TRUE);
}
return(FALSE); // no error; command handled OK
}

workingmailing@163.com wrote:

Time, it is the code,

case VR_FIFO_RST is for reset EP2 quad IN buffer

Why don’t you have this in every case?

EP0CS |= bmHSNAK;

You’re required to set that bit to complete a control transfer.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

hi, Tim

only the following part is related to EP2 Quad buffer reset.
It doesn't work now, do you have comments on the follwoing code for reset EP2 IN quad BUFFER?


case VR_FIFO_RST:

SYNCDELAY;
FIFORESET = 0x80;
SYNCDELAY;
FIFORESET = 0x02;
SYNCDELAY;
FIFORESET = 0x00;

break;

workingmailing@163.com wrote:

only the following part is related to EP2 Quad buffer reset.
It doesn’t work now, do you have comments on the follwoing code for reset EP2 IN quad BUFFER?

My guess is that your firmware is never seeing this request, because you
did not properly terminate some previous request by resetting the
bmNSNAK bit, so your reset request is stalling. You are not following
the rules. It’s no surprise that it doesn’t work as you expect.

By the way, in a previous message, you said that you were confident that
this code was being executed. Why did you say that? You aren’t sending
a response, and you aren’t toggling an LED. How can you possibly be
confident this code is being run?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.