Problem loading firmware on on older FX USB microcontroller using newer CyUSB.sys driver...

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hello,

   
    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??   
   
    
Manuel   
0 Likes
7 Replies
Anonymous
Not applicable

... Also forgot to mention that our .HEX file for the FX1/FX2LP is 9619 bytes in size and always loads totally fine on the new hardware using the same load routines of our software and/or CyConsole/CyControl.. regardless of size.

   

... while our firmware for the older FX hardware is only 4138 bytes... but fails to load using the same load routines of our software and/or CyConsole/CyControl (with the added chages for CPUCS address RESET and maximum internal address value) DEPENDING on size.

0 Likes
Anonymous
Not applicable

 Hi,

   

 

   

Please create a tech support case at www.cypress.com -> Support -> Tech support. One of our engineers will take a look at the issue and will help you out.

   

 

   

Regards,

   

Gayathri

0 Likes
Anonymous
Not applicable

Hello,

   

I actually did end up opening a case for this problem (Case # 1887119173)... but still wanted to see on here if someone else has run into this similar problem.

   

Thanks,

   

Manuel

0 Likes
Anonymous
Not applicable

 Hi,

   

 

   

Noted the case number. We would be supporting you through the case.

   

 

   

Regards,

   

Gayathri

0 Likes
Anonymous
Not applicable

 Is there a resolution to this issue? We have a similar situation and like to know if we can move away from the two satge driver (ezloader.sys then ezusb.sys) and use CyUSB.sys and script instead for some old devices.

   

Thanks.

0 Likes
Anonymous
Not applicable

 Hi,

   

 

   

Yes we do have a resolution for this. Ffirmware download to FX using CyUSB.sys is seen to have issues when done in chunks greater than 64 bytes. We have a utility that generates scripts which does the firmware download in chunks of 64 bytes. Please create a tech support case where we can share you more details.

   

 

   

Regards,

   

Gayathri

0 Likes
Anonymous
Not applicable

  Hi,

   

 

   

Yes we do have a resolution for this. Ffirmware download to FX using CyUSB.sys is seen to have issues when done in chunks greater than 64 bytes. We have a utility that generates scripts which does the firmware download in chunks of 64 bytes. Please create a tech support case where we can share you more details.

   

 

   

Regards,

   

Gayathri

0 Likes