I have an issue with a FX2LP USB device not restarting after my linux-libusb based application has been killed with Ctl-c during data transfer.

It seems that the USB bus is going away while power is still applied (My device is using external power supply).

Only powercycling the device by replugging powwer cable helps.

What is the right way to solve this issue?

I implemented a dirty trick in the FX2 firmware that seems to solve the problem:

I implemented a user command (VX_11) that calls all the rutines implemented in TD_Init() (see code bellow).

I then call this user command in the device opening phase (in the libusb driver).

void TD_Init(void) // Called once at startup

{

initialize_board();

}

void initialize_board(void) // Called once at startup

{

CPUCS = 0x10;                 // CLKSPD[1:0]=10, for 48MHz operation

IFCONFIG = 0xE3;

...

...

}

//user command:

BOOL DR_VendorCmnd(void)

{

...

...

case VX_11: 

initialize_board();

break;

}

For some reason I don't quite understand, I need to send this user command twice otherwise the bus is still dead. 

I am sure there is a better/clean way to solve this issue. 

Note: The reset pin of the cypress chip is connected to VCC.

Thanks, malik cisse

Hi Malik,

I think there is an alternate way.Here what you can do is to implement a vendor command which will re-enumerate your device. You can use the following code to do that :
" 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;
"

If that does not work, there is one more way.You can issue an 0xa0 vendor command which is implemented in FX2LP hardware to write 0x01 at 0xE600 register which will reset the device.And when again you will write 0x00 at 0xE600 register the device will come out of reset.
The way to issue 0xa0 vendor command is:
1. Req code => 0xa0
2. value field(high and low) => 0xE600
3. Length => 1
4. data => 01 for reset and 00 for reset release in the payload of data phase.

Hi Shub,

In the new CyAPI.net for CyUSB.sys, there is a function CyFX2Device::Reset. The documentation said :

public void Reset(int hold)
Description
The Reset method of CyFX2Device halts or starts the FX2 chip.
The hold parameter determines the effect of the Reset command.
hold == 0 causes the FX2 to resume execution.
hold == 1 halts the chip.

My question is : what's the internal operation of the Reset function. Is it same with the 0xa0 vendor command as you described?

In addition, there is another function called Reset which is defined in  CyUSBDevice class.
public bool Reset ( )
Description
Reset causes the USB device to be reset to its initial power-on configuration.
 
So what's the difference between these two Reset functions?

Thanks. 

Hi,

The first reset writes to CPUCS register (0xE600) of FX2LP through 0xA0 vendor command to reset or run the 8051.

The latter sends a USB bus reset and then re-enumerates the device.

Regards,

Anand

Hi Anand,

Thanks for your quick reply.

For the first case, do we need to process the 0xa0 vendor command in the firmware? or this command will be done by hardware automatically?

Currently we are developing a real-time imaging device. The real-time images are transfered through 68013A to PC. At the beginning of each frame we put some sync header. Occasionally we found that some frames will have some random offset. We think that these offsets may be caused by some error on 68013A FIFO buffer. When we detect that the frame sync header is not correct, we want to reset the 69013A. 

So my question is : for our case, which Reset method is better?

Thanks,

Mczhao

Mczhao,

0xA0 will be processed automatically by the hardware.

In the first reset you'll just be resetting the 8051 not the FIFO buffers. Using the latter you can write code in the USBReset ISR to do the kind of resetting internal states + buffers that you want to do.

You can keep it simple by implementing a vendor request to do this. Why do you want to complicate it with reset because the reset will send USB reset and enumerate all over again rather than that a vendor request will cost you less time for doing the same.

Before going into that it would be a good idea to debug to the reason behind the out of sync issue.

Please let me know the following details,

What type of endpoint are you using? Are you seeing data corruption or just the frame going out of sync all of a sudden? What driver are you using?

Regards,

Anand

Hi Anand,

Thanks for your suggestion.

We are using the bulk endpoint to transfer the real-time image data and control data. The configuration details are:

EP2CFG=0xa0; // out, buffer size = 512 bytes 

EP6CFG=0xE0; // in, buffer size = 512 bytes

EP2FIFOCFG = 0x11; //AUTOOUT = 1, WORDWIDE = 1, 16 bits

EP6FIFOCFG = 0x09; //AUTOIN = 1, WORDWIDE = 1, 16 bits

We didn't see data corruption. We only found the frame out of sync problem. And the probability  of this out of sync problem is very low.

We are using the CyUSB.sys, which is dated on 2005.03.03. The OS is Windows XP 32 bit x86. For the maximum bandwith efficiency, we are using the asyn transfer mode to read in the image data.

In addition, at some situation   68013A chip will hang after long time data transfering (maybe one time per 24 hours).   In this case, we can't transfer any data from PC to FPGA or from FPGA to PC. The 68013A chip can't response any data in/out request.  And when we download code to FPGA through the FPGA-JTAG cable while the image transfer is on going, the 68013A chip will hang.

Another question is : in the new CyAPI for .NET, how do we call the vendor request through C# or other .NET programming language? We can't find the related functions in the documentation.

Thanks,

Mczhao 


 

Hi,

Migrating to the latest driver available as part of SuiteUSB would be a good idea.

If you are not seeing data corruption, you're most probably missing packets that is making you go out of sync. Does your system have the possibility of sending out packets longer than what is requested. Say the host app requests (69*512 + 90) and say the device sends 70*512. There won't be enough space the last packet and hence it will get discarded :(

Also does your device send short packets or is it always 512 bytes?

I've not tried accessing CyAPI.lib from C#. Let me see if i can get something on that for you.

When you say you're not able to transfer from FPGA to PC and PC to FPGA. On the PC side are you seeing NAKs all the time, on the FPGA side are you seeing empty flag always??

Regards,

Anand

Hi Anand,

Recently we have tried the latest driver and CyAPI for .NET included in SuiteUSB. The problem is same.

We always use the 512 bytes and the size of host requesting and device sending are always same.

When I said the 68013A is hang, I mean that in the reading thread on PC side, the WaitForSingleObject is always time out. And on the FPGA side, I always see the full flag of the 68013's FIFO buffer. So the FPGA can't send any data and the host app can't receive any data. We don't know in this case what happened in the 68013 chip. And when our host app detected this case, how do we reset or recover the 68013 chip programatically?

Thanks,

Mczhao

Is it possible to check whether this out of sync problem is due to missing of multiples of 512 bytes worth ot data?

This may not necessarily be a hang of the FX2LP chip i.e. If host does not read the packet then FX2LP buffer will fill up soon and FPGA will see the full flag and won't be able to send packets until host starts reading packets.

When the hang happens is it possible to see if you're able to read a packet or two using CyConsole?

Regards,

Anand

Hi Anand,

Yes, the out of sync problem is due to missing of multiples of 512 bytes data.

When the hang happens, we have tried to use CyConsole to read data, but it failed. In this case, even PC host app send read request continously, the 68013 just have not any response.

Yesterday we found another problem. We connect the PC and 68013 device through usb cable. At the same time, we insert a usb udisk and copy some files to the udisk through Windows explorer. When we unplug the usb cable, the whole usb bus seems hang. The progress bar of udisk file copy is stopped. When we re-plug the usb cable, in the device manager operating system can't recognize the cyusb device. And in the Cyconsole, it still can't recognize the cyusb device and can't read or write any data. We do this experiment on several PC, the same problem exists. The firmware is the official firmware downloaded from Cypress website, and the driver and API are all latest version.

Thanks,

Mczhao
 

Hi mczhao,

This suggests that your USB interface is most probably not upto specifications. Did you run USB2.0 electrical compliance tests on the USB interface?

Since this happens after sometime it is most probably due some operating temperature at which the USB interface of the device goes below USB2.0 specification. Try running USB compliance once you see this issue.

Regards,

Anand

Hi Anand,

What USB interface do you mean? PC host controller, or 68013 device ? We have tried several different PC (with different motherboard) and different 68013 boards (from different manufactuer), and the problem will reproduce 100%. So we think this is a problem of 68013.

Thanks,

Mczhao 

Hi,

By any chance do you have a CATC that you can hook-up to the interface and see what is happening. If you can capture the traffic when this issue occurs it would helpful to isolate the actual issue.

Regards,

Anand