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?
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.
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.