EEPROM reset shouldn't happen, something fishy is going on. Maybe parameters get overwritten upon writing to EEPROM?
I made EEPROM parameters saving helper, which has CRC8 check.
Try this component and see if problem persists. (There are two demo projects there, one is very basic.).
Maybe this will help.
I created a version of my application code to run off the CY8CKIT-059 target PSoC5 and the same application to run off the CY8CKIT-059 KitProg board. In both cases I saved configuration data to EEPROM located at the very beginning (Sector 0 Row 0) of EEPROM memory.
I could reprogram the firmware in the target PSoC5 with no issues. However, reprogramming the firmware in the KitProg board lead to the first set of configuration bytes in EEPROM to be corrupted.
The root cause: The KitProg has it's own program (Bootloader) and to load new app code into it requires a BootLoadable component. The BootLoader in the KitProg stores the address of the BootLoadable code in the first 4 bytes of EEPROM. That way on reset, the KitProg bootloader code will know where in FLASH to start executing the app you installed.
To "fix" this I moved the configuration data into Sector 1 instead of Sector 0. In theory for the KitProg, I could have moved the configuration data to Sector 0 Row 1 (instead of Sector 0 Row 0). This would have put it past the bootloader application jump vector. Once I moved the config data, I had no problems with corrupted EEPROM data.
Note: KitProg is capable of only one bootloable Application. KitProg2 and KitProg3 have more than one. Therefore if these others use the same strategy of placing the Application jump vectors in the first bytes of EEPROM, you might be advised to place your Application data at least starting in Sector 0 Row 4.
Note 2: Based on Cypress' current bootloader strategy, if multiple bootloadable Application apps need to store in common EEPROM memory, some system strategy needs to be developed to coordinate EEPROM allocation across applications. At this time, I am not aware of any tool provided by Cypress to handle EEPROM resources across Applications. This would have to be done manually by the SW designer.