The eeprom is not flash (as emulated eeprom) so no need to exclude it from protection, it lies outside of the normal address space.
From the datasheet -
There is no need of APIs to read from the EEPROM. The entire content of the EEPROM is
mapped into memory space and can be read directly. EEPROM allows read access at the byte
level. The following defines are used for reading EEPROM:
CYDEV_EE_BASE The base pointer of the EEPROM memory
CYDEV_EE_SIZE The size of the EEPROM memory space in bytes
CYDEV_EEPROM_ROW_SIZE The size of a row of the EEPROM in bytes
Using the base pointer, individual bytes of the EEPROM memory can be read.
There is a project available on start page of Creator so you can look at how R/W to EEPROM
Basically you have a set of data that you want stored in EEPROM. As the definer of the data
typically you write a rows worth at a time to the EE. And as definer you know its size and how
its packed into the row format. That in turn gives you the # rows you will be writing, 16 bytes at
a time. In Creator, double clicking *.cydwr will lead you to a group of tabs, and one of them
is flash protection. So you would un protect those rows that you intend to write.
Note .map file will show you whats mapped into all memory regions.
Memory map for PSOC 3
Thanks. I think the memory map was exactly what I was looking for. Between that and CYDEV_EE_BASE, the addressing makes sense now.