Approximately 10 years ago, we first developed our company hardware to utilize the FX USB microcontroller. At that time, we used the available EzUSB.sys developmental driver to develop all of our software to control the microcontroller… and since then all of our FX software/firmware has worked properly.
In the past few years we’ve successfully upgraded/migrated our hardware to the newer FX1 & FX2LP (using the CyUSB.sys driver and utilizing the CyAPI.lib library), in hopes of phasing out the old FX chip hardware/software. Again, all of the new FX1/FX2LP firmware developed works fine with this new hardware.
However, many of our older customers still have/use the older FX hardware/software (which uses the old EzUSB.sys driver)… and recently we’ve been getting many complaints from these older customers about performance due to Win7 and 64 bit OS issues, etc. Therefore, we are in the process of trying to resolve these problems for our older customers. So in doing research, we found out that the newer CyUSB.sys driver can actually be used to control the original FX chip (instead of the EzUSB.sys driver), as well as the FX1/Fx2LP… therefore we are now in the process of converting all of our older FX software to use the CyUSB.sys driver and CyAPI.lib library instead (using all the new function calls/API’s/etc).
Naturally we assumed that since the FX hardware remained the same, that the old FX firmware would still work on the older chip (even using the new driver)… and would not need to be changed, since all the register addresses, i/o ports, i2C routines, etc remained the same. However, for some weird reason we are having issues now with the same old firmware on the same old FX chip now using the CyUSB.sys driver. We are certain it’s not an issue with our particular software routines loading the actual firmware files versus Cypress utility software (ie., CyConsole or CyControl) because we even create script files from the hex file defining the CPUCS register address as 0x7F92 for the old FX chip (instead of 0xE600 for the FX1/FX2LP), as well as defining the Maximum Internal Address of the old FX chip as 0x1B3F (instead of 0x4000 for the FX1/FX2LP)… as specified in the Cypress literature for converting to the new driver. Yet, the script files don’t even work using CyConsole or CyControl.
(NOTE: we also added these same address changes to our software routines for loading the hex files)
The strange thing we noticed is that once code loaded to internal code memory surpasses exactly 1024 bytes, it fails to work (transfers fail, I2C read/write fails, I/O ports fail, etc). We know this because we started removing certain parts of code from the firmware to create different test versions of firmware that only use 1 or 2 endpoints/pipes instead of all the ones used in our original firmware code… and the smaller versions of firmware work fine when loaded (i.e., the endpoint transfers work and no errors, i2C read/write works, i/o ports work, etc). But when we slowly combine all of the code back to the original, all transfers, etc fail. At first we weren’t sure what was going on, but then we noticed a pattern that as the size of the code loaded to the chip surpassed 1024 bytes the firmware ceased to work. In fact, to test this we even kept adding sequential NOP calls to the initialization part of the code where they would not interfere at all with functionality until we came up with a script file that loaded exactly 1023 bytes of code which worked and also a script file that loaded 1024 bytes of code which did not work. Anything below 1024 byes loaded works, while anything above 1024 bytes does not… in our own software, the CyConsole software, or CyControl software. They all behave identically regarding this. But we have no idea why this would be the case, since even on the older FX chip the code size limit is 6976 (0x1B40) bytes which is still much greater than 1024 (0x400) bytes. So there should not even be a problem like this.
(NOTE: our original firmware for the old FX chip only loads a total of 1428 bytes to code memory… much smaller than the limit… and its all loaded sequentially starting at address $200, as displayed in the CyConsole/CyControl output windows.. and we only use BULK transfer)
Can anyone offer any ideas or assistance on this matter and/or please explain this… so that we may resolve this problem??