General

It is not recommended to have such a design. Omitting an EEPROM from a design requires user to run a script file to download firmware to the device when it comes up with our default VID/PID (0x04B4, 0x8613), which is not for use in an end product. If all of our customers used this method, each would be linking their drivers to it, replacing someone else's link. When designing a consumer product it is recommended to use a small EEPROM and put a proprietary VID/PID in it. When the device enumerates with the proprietary VID/PID on the small EEPROM, we can run a script to download the firmware into the device and enumerate it with a new VID/PID and bind it to a custom driver.

Please refer the KB article Firmware Download Using Script for EZ LOADER and the Script method of downloading firmware respectively.

As part of an endpoint initialization or reset, the endpoint FIFO should be cleared (flushed). This is done by sending the INPKTENDFLUSH command with the appropriate endpoint identifier upper bits specified. Sending an INPKTEND with 0xF0 data will flush all FIFOs.

 

The most current version is V1.96.

Hex files are ASCII representations of binary data (bix). For a discussion of the hex file format see http://www.keil.com/support/docs/1584.htm.

The hex2bix utility is provided to assist in converting a hex formated file to the bix format to create iic images to load in your serial EEPROM. The .IIC files can be downloaded to the EEPROM using the EZ-USB CyConsole or Control Centre utility. The Hex2bix utility tool is present under C:\Cypress\USB\bin once the CY3684 EZ-USB FX2LP Development Kit is completely installed. The hex2bix utility is a DOS program. A detailed description of how to go about using the utility is present in application note  Using the Hex2bix Conversion Utility-AN45197.

Attached is an example that demonstrates how a Silicon ID is read from an enCoRe II device. The silicon ID is stored in table 0 and is returned in locations F8 and F9 in the RAM when a table read SSC call is made. The ID is then moved into another location in the RAM (done because the EEPROM write routine uses the last 8 bytes of the RAM) and the EEPROM write routine is called to write this value to the flash. Make sure the flash security file is unprotected ? to be able to write to the flash location and to be able to read out the value using a MiniProg or ICE cube.

Yes, there're a few places in the firmware that need some modifications. For example,
 

1- Change the definitions of CLKH_DATAH, CLKH_DATAL, CLKL_DATAH, CLKL_DATAL to match with Table 13.1 in the data sheet.

2- Change the values of SDATA and SCLK labels.

3- Change the send_0 and send_1 routines.

Yes, it is possible to use FX2 for the application described above. Mode 2 would be relatively straightforward considering that we have a  reference design for this very purpose.

For mode 1, here are some of the design considerations:

1) If the FIFO/RAM is connected to the address/data bus of the 68013 let's say, you could have separate code (from Mode 2) running that knows how to take the contents of the FIFO/RAM and transfer it to the IDE drive.

2) See page 10-58 of the FX2 Technical Reference Manual, and you'll find that in point 3., the contents of the FIFO buffer can be edited manually. Then you could launch the GPIF transaction with those contents. However, you'll need some kind of flag to alert the firmware that this happens because FX2 is not connected to the USB bus. This event may be a status pin from the FIFO/RAM that the FX2 firmware detects.

3) Consider using the Slave FIFO interface instead of the address/data bus. The IDE drive data bus must be tri-stated. You could write data into the Slave FIFO (e.g. 512 bytes), switch to GPIF mode by writing to the appropriate bits in the IFCONFIG register, then launch the GPIF transaction to burst the data out to the IDE drive. This mode of operation was something that was not simulated, so unfortunately we cannot guarantee this operation. However, all indications are that it should work. For performing this operation, it is recommended that the FX2 stay in manual mode so that the CPU has full control of committing the data packets (like in page 10-58 of the Technical Reference Manual).

The Slave FIFO interface would be a lot faster than the regular CPU address/data bus, so this would be the fastest method to pump data through. For an estimate of the bandwidth numbers over the address/data bus interface, please refer to page 12-6 in the FX2 TRM. At 48MHz, you would be able to achieve about 23MB/s over the address/data bus.

Yes, but very limited.

The Combi Mouse design is available in both C and assembly.

The Cypress CY7C63xx devices use an exceptionally small PROM cell that allows us to sell OTP devices at a price nominally only achieved with masked mcus. This allows us to offer all the advantages of OTP - uncommitted inventory, fast lead time,

etc. at the same price as you would nominally pay for masked parts. There are no setup fees of any kind for this service. Contact Pam Bickel (xpb@cypress.com) in our marketing team (858- 613-7932) for information on lead times and unit cost.

ZDBs that has the feature of "Spread Aware" or "Spread Compatible" should be used. These parts has a wider loop band width, hence able to pass the spread signal through without loss. Some of these parts has the "S" in their name, ie. CY23S09, as supposed to the CY2309 which is not Spread Aware.