Manage Working Flash Space for Both Cores of PSoC® 6 – KBA224173

Version: **

 

Question:

A building error might occur for PSoC® 6 projects in which both cores occupy the working flash. How can I manage the working flash space for both cores properly?

 

Answer:

 

For PSoC 6, by default, the complier always assigns both cores with full range of working flash (0x14000000-0x14008000) for EEPROM emulation. Both cores operate on the same flash object. A building error would occur if there is an out-sync operation on the memory range from any single core.

If more than one component occupying the working flash is simultaneously under used, for example, Bluetooth Low Energy (BLE) and EEPROM, a building error will occur while generating the elf file. The error occurs because there is a working flash region allocated for BLE to store the Bonding list, and this region will only be allocated to the core where the BLE host lies. This out-sync between the two cores causes the building failure.

 

Follow these methods to avoid the building error:

Method 1: Allocate working flash for only one core

If only one core needs to access the working flash, manually separate the other core by deleting the relevant section from its linker file. Here, assume that only Arm® Cortex® M4 accesses the working flash, then comment or delete either of following code snippets in the Cortex M0+ linker file(cy8c6xx7_cm0plus.ld):

Snippet 1:

em_eeprom         (rx)    : ORIGIN = 0x14000000, LENGTH = 0x4000     

Snippet 2:

/* Emulated EEPROM Flash area */

.cy_em_eeprom :

   {

KEEP(*(.cy_em_eeprom))

} > em_eeprom

where cy_em_eeprom is the only section defined in the em_eeprom space by the system automatically.

 

Method 2: Split working flash space for two cores respectively

You can implement this method by modifying the respective linker files of the two cores:

cy8c6xx7_cm0plus.ld:

em_eeprom (rx)    : ORIGIN = 0x14000000, LENGTH = 0x4000    

cy8c6xx7_cm4_dual.ld:

em_eeprom         (rx)    : ORIGIN = 0x14000000, LENGTH = 0x4000

By default, the complier assigns full range of working flash for both cores (ORIGIN = 0x14000000, LENGTH = 0x8000). In method 2, you manually split it into two separate parts, one for each core. Any action issued from one core on its own working flash space will not impact the space specified for other core.

The disadvantage of this method is that the range of memory space is fixed for each core once it is allocated. You need to be aware of the rough memory size required for each core and make proper allocation.