IMPORTANT: Cypress Developer Community currently doesn’t allow sign-in to prepare for the upcoming transition. To learn more, check out our announcement.
Showing results for 
Search instead for 
Did you mean: 

PSoC 5, 3 & 1

Not applicable

I have my own FLASH update utility that runs in RAM. It has to run in RAM including all constants/variables so the rest of flash can be updated.


It was easy enough to get my routines into RAM using the documents at:


But these routines call CyWriteRowData() and CyWriteRowConfig which are in CyFlash.c which is generated code from Creator. I have to get these into RAM as well or else the flash updater won't work as FLASH might change during the download!


While I could go in and manually add the


__attribute__ ((section(".ramcode"))) void ramFunc(void);


to every function in CyFlash.c, it seems like there must be an option in the customer linker file cm3gcc_custom.ld that would push all routines from this file into the .data section instead of .text.




Does anyone have an idea how to do this? Google searches keep coming up with details that don't match what I'm trying to do...

5 Replies
Not applicable

The GCC linker documentation is at:


but when I just put in:


.data : ALIGN(8)
    __cy_region_start_data = .;

    *(.got.plt) *(.got)
    *(.data .data.* .gnu.linkonce.d.*)
    . = ALIGN (8);
    _edata = .;
  } >ram AT>rom


But this gives me a linker error - Build error: cannot find CyFlash.o


If I change it to *(CyFlash.o)


then it builds but the routines in the file are still in .text.


From the .map file:


                0x00005188       0x90 .\CortexM3\ARM_GCC_473\Debug\I2CComplianceChecker.a(CyFlash.o)
                0x00005218       0x24 .\CortexM3\ARM_GCC_473\Debug\I2CComplianceChecker.a(CyFlash.o)
                0x00005218                CySetTemp

Esteemed Contributor

Consider filing a CASE with a link to your post here.








To file a tech case -





“Technical Support”


“Create a MyCase”




Regards, Dana

Not applicable

OK - I opened a MyCase with a link to this post.


Thanks Dana

Not applicable



1. It is not possible to directly include "CyFlash.o" or the object file of any ".c" file generated by PSoC Creator, in a section by modifying the LD file. The reason behind this is because the functions belonging to the object file will be included in Flash by default and hence adding it into SRAM would throw errors saying that there are multiple definitions. It is normally possible to exclude an input file from a wildcard using the EXCLUDE_FILE syntax ( ). However, CyFlash.o is stored inside the project's .a file, so it cannot be excluded individually from the flash section. So, the only way to place all the functions in that ".o" file in your custom section would be to include "__attribute__" syntax in each and every function declaration in the ".h" file (CyFlash.h).


2. If you have defined some source and header files on your own and if you would like to place the ".o" file corresponding to a header file in the SRAM/ custom section, you need to follow the following steps: (i) In the .data section, add the full path & file name with the .text section references, for example: .\CortexM3\ARM_GCC_473\Debug\myfile.o(.text .text.*) This includes myfile.o in SRAM. (ii) I need to exclude this ".o" file from Flash so that there are no multiple definitions for the same function. So,in the .text section, replace " *(.text .text.* .gnu.linkonce.t.*)" with "*(EXCLUDE_FILE(.\CortexM3\ARM_GCC_473\Debug\myfile.o) .text EXCLUDE_FILE(.\CortexM3\ARM_GCC_473\Debug\myfile.o) .text.* .gnu.linkonce.t.*)". This removes myfile.o from Flash.

Not applicable

My solution to this problem is to copy the few routines I needed from CyFlash.c and rename them MyFlash.c with the __attribute to push them into RAM instead of FLASH. I had to copy a couple of small routines from CySpc.c as well and replace memcpy with a simple for-loop (memcpy would also be in FLASH).


I think I've now got all this code in RAM so once I call it it'll always be in RAM and I can thus rewrite all of FLASH with the downloaded image. There is always a chance of failure which would require reprogramming via a miniprog3 but this chance is low enough that I can accept it.


Not as elegant as simply pushing the routines from FLASH to SRAM but I tried all sorts of syntax but either got loader errors (with very little diagnostic info) or duplicate definitions as mentioned above.