0x14000000 is start address of working flash, which is mainly used for purpose of EEPROM emulation. All eeprom space is mapped for both cores. I guess you might involve EEPROM component and define custom data array for each core in your project. Therefore, there is conflict between two cores. If it is the case, you can split EEPROM space into two parts for each core by modifying linker files:
I don't use the EEPROM component, but I use the BLE component which, as I understand, uses the emulated eeprom to store the bonding data, but I don't understand why it would have to be in the application image.
The reason is you need to program the EEPROM region with the initial BLE bonding info and hence the image has data placed at 0x14000000 so that when you parse and program the cyacd2 file, you also program the 0x14000000 region as well. Though there are not much info in the initial bonding data, it is better to erase the section and keep it clean when you first program.
BLE bonding does not use any special or dedicated memory but it uses the emulated EEPROM region shared with application for bond data storage.
If you don't want the emulated eeprom data to be programmed from the cyacd2 file, then simply make the section as "(NOLOAD)" in the linker script as shown below. This will ensure linker does not load the section in the hex or cyacd2 file. Note that this will also not any user data you place as well - you can create a new section for user data if you want to load the data from your hex/cyacd2 file.
/* Emulated EEPROM Flash area */
} > em_eeprom
Meenakshi Sundaram R