2 Replies Latest reply on Mar 7, 2020 8:42 AM by LePo_1062026

    Update fw reset some eeprom cells




      I am development an application that save in eeprom some data with Psoc5. When i update the firmware with the bootlader host some times when the firmware start, i found the some eeprom cells resetted. I have seen this problem because i found, after power-up, the variables saved in eeprom resetted abnormally. After update the firmware, turning on and off the board this problem don't verify never again. In fact the variables aren't longer reset in a strange way. Why there are this problem that  the eeprom cells some times are resetted after i update the firmware ? i repeat this problem doesn't verify always, but some times.


      Best regards



        • 1. Re: Update fw reset some eeprom cells


          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.

          Re: myEEPROM: component to save/recall application settings in EEPROM between power offs

          Try this component and see if problem persists. (There are two demo projects there, one is very basic.).


          • 2. Re: Update fw reset some eeprom cells



            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.