I came across this thread and I have extensive experience with the EZusb FX2 using USB2 high speed mode (480MBit) hooked to an FPGA. I also have a rather expensive CATC hardware protocol analyzer, so I can verify that some of the problems that I have are actually with the EZUSB.. but cypress doesn't care. Let me tell you, the ezusb usb core has plenty of gotchas on it's own. (The 8051 core is bug-free it seems though.) 1. The "sram" download feature that all believe to be a great feature is in fact a curse in my opinion. You will probably spend additional development time developing or modifying bootloaders for every possible operating system; Windows, MacOS (68K), MacOS (intel), linux. You also will have to make sure they work under 64-bit windows. And 64-bit windows REQUIRES signed drivers for kernel mode bootloaders. So right there you need to buy a verisign signature ($499 per year) and the signing tools are crap and only run right on windows XP. You can't use a 3rd party signing certificate like you can for apps. 2. The EZUSB FX2 often looses it's serial eeprom, so you have dead boards in the field that you can't boot or fix, just like your flash problems. Even if you never write to it, it manages to become corrupted. But there's no chance of a backup bootloader like you can do with flash. 3. We have had a fair share of bad IC's from cypress. How responsive were they? 2 months investigating it and I had to call every other day. They really don't care. This is like a side business for them. 4. The EZUSB engine sometimes duplicates received packets seen by the 8051 core endpoints (GPIF endpoints were OK). They are not duplicated on the USB line; it is a hardware bug that is really difficult to catch, but it's the FX2. Cypress told me they don't have a CATC analyzer so they can't look into it. It is related to the buffering modes. Quad buffered seems to work; single or double had some problems. 5. The hardware engine takes a variable amount of time to compute packet checksums & send an AK back to the host. It really limits the amount of data you can push through; I would never use this for a hard drive interface; the dedicated bridge chips would be much better. I have had some problems with the silicon labs USB products also. I generally like them a lot, but 1. Silicon labs are expensive for production parts 2. The CPU core can lock up if there is momentary noise (or the clock drops out) on the USB lines. Makes your product unreliable. 3. Just momentarily short the D+ and D- lines going to a silicon labs chip to simulate this. The core stops. Cycling power is the only way to get it working again. There are a lot of amazing looking cortex USB parts out now. All are only 12mbit usb (the atmel at91sam is 480mbit but still not out.) LPC13xx series for $2.50 is amazing, and the LPC17xx for a little more gets you extra uarts & flash. I am trying these out now.. the developer kit with compiler & reusable jtag is only $30! Look for the LPCXPRESSO. I would also highly recommend (if you can), stick with using usb 2.0 full-speed (12Mbit) rather than high speed (480mbit). You will have fewer problems caused by your user's poor quality usb cables, questionable hubs, motherboards, or chipsets. It seems every month we find another motherboard that has a hiccup with high speed usb transfers. Best luck to all. Dave Vitaliy-14 wrote: > > Funny NYPD wrote: >> Those are new silicons, no surprise to me, will be full of bugs. > > PIC24H has been around for several years now. We had concerns about using > a > "new, unproven" chip but so far we've been able to work around the bugs. > Started using 33F/24H back in 2008. > > Vitaliy > > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > > -- View this message in context: http://old.nabble.com/MCHPFSUSB-USB-stack-bug-tp27165727p27502446.html Sent from the PIC - [PIC] mailing list archive at Nabble.com. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist