3 Replies Latest reply on Jul 1, 2019 1:48 AM by LinglingG_46

    PSOC 63 Emulated EEPROM confusion - size restrictions, overhead?

    AdHi_2630466

      Hi All,

       

      I have been experimenting with the Em_EEPROM component with CY8CPROTO-063-BLE.

      It is working nicely, with only one problem: It seems like I'm only able to use 14592 Bytes(???) out of the 32kB. Let me explain how I got here

       

      First I thought I would set the EEPROM size to 16386Bytes(???), no rebundancy, no wear level factor. I got EepromStorage Validation Failed error right the way:

       

      Then I thought OK, let's reduce the size. The closest I could get without any errors is reducing Size by 256 to 16128:

       

      This gets me through to Build, with "ERROR: region `em_eeprom' overflowed by 3072 bytes" and it points to the cm4_dual.ld linker file.

       

      The next step is to reduce Actual EEPROM Size by 3072 bytes to prevent this overflow, leaving me with 14592 EEPROM Size (29184 Actual Size (bytes)).
      This compiles and works perfectly fine, as long as I read/write with uint8_t buffer[14592].

       

       

      Can anyone help me understand what is happening under the hood of Em_EEPROM component, and why can I only use 45% of the EEPROM memory effectively?

        • 1. Re: PSOC 63 Emulated EEPROM confusion - size restrictions, overhead?
          LinglingG_46

          As my understanding, even though you set the Redundant copy "No", the IP still has a copy of each row. If you choose the Redundant copy "Yes", it will have a second copy.

           

          If I open up space 16128 Bytes, it will have no error.

          Could you attached your test project?

          • 2. Re: PSOC 63 Emulated EEPROM confusion - size restrictions, overhead?
            AdHi_2630466

            Is there any detailed documentation out there about the Em_EEPROM that describes this data management?

            With Rebundanty Copy turned on the actual size in bytes will be 4x the EEPROM Size field.

             

            I am almost sure that my 3072bytes overflow compiler complaint was because of the BLE stack also using the same memory space. I can prove this by turning (NOLOAD) on/off in the linker scripts for the EEPROM section. With (NOLOAD) I will retain contents of the EEPROM as well as all my saved bonding data after each Debug/Program cycle.

            • 3. Re: PSOC 63 Emulated EEPROM confusion - size restrictions, overhead?
              LinglingG_46

              You can check the datasheet that EEPROM Size:

               

              Sets an EEPROM size. The size should be rounded up to a full EEPROM page size.

              The page size is specific for a device family. For PSoC 4 the page size is 64 bytes, for

              PSoC 3/PSoC 5LP – 128 bytes, for PSoC 6 – 256 bytes. Min size is 1 page/row. Max

              Size = available flash.

               

              The datasheet EEPROM Size description specified em_eeprom PAGE sizes, which is equal to the half of the ROW size (another half is used to store internal component data).

               

              PSoC6 page size 256 bytes, row size 512 bytes.

              So: With Rebundanty Copy turned on the actual size in bytes will be 4x the EEPROM Size field.

               

              Currently we making rework of Em_EEPROM middleware for PSoC6 due to found issues and customer response. New Em_EEPROM will include Simple mode, which use flash memory region directly, without any additional internal data, so in that mode Actual EEPROM size will be equal to requested by user EEPROM size.