1 Reply Latest reply on Mar 11, 2020 1:53 AM by ShifangZ_26

    locked memory

    PaVo_4660581

      For a CCG4, I would like to save in a fixed user memory location some hardware details for the part.  By doing so, I will be able to write one single software application that will configure itself differently based on the hardware detail memory.   In this manner I can load a special build into each controller the first time and then after that write a generic controller application that will self identify.  Is it possible to do this in the linker file?  If so, how do I do that?

       

      Thanks in advance

        • 1. Re: locked memory
          ShifangZ_26

          Hi ,

           

          May I know the linker file you mentioned is cm0gcc.ld?

          >> If you want to change the cmogcc.ld file, the answer is we do not recommend you change this file directly.

          The further manual of Linker script for ARM M could get it from https://support.codesourcery.com/GNUToolchain/

           

          If you just want to have some flash row for storing the specified value, you could implements in CCG4 firmware via CCG4 SDK. You could download CCG4 SDK from the link as below.

          https://www.cypress.com/documentation/software-and-drivers/ez-pd-host-software-development-kit

           

          The firmware of CCG4 have implemented METADATA into the last flash row. You could insert your contents into the 2nd row before METADATA. The data structure you could find out is:

          /**

          * @brief CCGx Firmware metadata structure

          *

          * This structure defines the format of the firmware metadata that is stored

          * on device flash. The boot-loader uses the metadata to identify the firmware validity.

          * location, size, start address etc. The metadata for the two runtime firmware images

          * (FW1 and FW2) are located at fixed addresses (for each CCGx part), allowing the boot-loader

          * to precisely locate and validate the flash content during boot-up.

          */

          typedef struct __attribute__((__packed__))

          {

              uint8_t fw_checksum;                  /**< Offset 00: Single Byte FW Checksum. */

              uint32_t fw_entry;                    /**< Offset 01: FW Entry Address */

              uint16_t boot_last_row;               /**< Offset 05: Last Flash row of Bootloader or previous firmware. */

              uint8_t reserved1[2];                 /**< Offset 07: Reserved. */

              uint32_t fw_size;                     /**< Offset 09: Size of Firmware. */

              uint8_t reserved2[3];                 /**< Offset 0D: Reserved. */

              uint8_t active_boot_app;              /**< Offset 10: Creator specific field. Not used in this implementation. */

              uint8_t boot_app_ver_status;          /**< Offset 11: Creator specific field. Not used in this implementation. */

              uint16_t boot_app_version;            /**< Offset 12: Creator specific field. Not used in this implementation. */

              uint16_t boot_app_id;                 /**< Offset 14: Creator specific field. Not used in this implementation. */

              uint16_t metadata_valid;              /**< Offset 16: Metadata Valid field. Valid if contains "CY". */

              uint32_t fw_version;                  /**< Offset 18: Creator specific field. Not used in this implementation. */

              uint32_t boot_seq;                    /**< Offset 1C: Boot sequence number field. Boot-loader will load the valid

                                                         FW copy that has the higher sequence number associated with it. */

           

           

          } sys_fw_metadata_t;

           

          You could use uint32 CySysFlashWriteRow       (uint32 rowNum, const uint8 rowData[]); API for flash loading.

           

          Best Regards,

          Lisa