5 Replies Latest reply on Mar 12, 2014 12:15 PM by eric.ryherd

    PSOC5 GCC linker locate all routines from a file in RAM instead of FLASH

    eric.ryherd

      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: http://www.cypress.com/?id=4&rID=57109#Section6

         

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

        • 1. Re: PSOC5 GCC linker locate all routines from a file in RAM instead of FLASH
          eric.ryherd

          The GCC linker documentation is at: http://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_21.html

             

          but when I just put in:

             

          .data : ALIGN(8)
            {
              __cy_region_start_data = .;

              KEEP(*(.jcr))
              *(.got.plt) *(.got)
              *(.shdata)
              *(.data .data.* .gnu.linkonce.d.*)
              CyFlash.o
              *(.ramcode)
              . = ALIGN (8);
              *(.ram)
              _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:

             

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

          • 2. Re: PSOC5 GCC linker locate all routines from a file in RAM instead of FLASH
            user_14586677

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

               

             

               

                

               

                      

               

            To file a tech case -

               

             

               

            www.cypress.com

               

            “Support”

               

            “Technical Support”

               

            “Create a MyCase”

               

             

               

            Regards, Dana

            • 3. Re: PSOC5 GCC linker locate all routines from a file in RAM instead of FLASH
              eric.ryherd

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

                 

              Thanks Dana

              • 4. Re: PSOC5 GCC linker locate all routines from a file in RAM instead of FLASH
                asha.ganesan

                Hi,

                   

                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 ( https://sourceware.org/binutils/docs-2.24/ld/Input-Section-Basics.html ). 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.

                • 5. Re: PSOC5 GCC linker locate all routines from a file in RAM instead of FLASH
                  eric.ryherd

                  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.