This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RM44L920: Flash CRC Calculation in sys.startup

Part Number: RM44L920


Tool/software:

Hi,

I am following SDL demo application but my project also uses FreeRTOS. I don't understand how to use SL_CRC_Calculate() function, how to calculate ulFlashEndAddr?

Is there some connection between .cinit and ulFlashEndAddr?

    crcAtInit_FLASH = SL_CRC_Calculate((uint64 *)((uint32)&ulFlashStartAddr), ((((uint32)&ulFlashEndAddr)-((uint32)&ulFlashStartAddr)) >> 3));

Here is my linker script. Is there need to change something in linker script?

/*----------------------------------------------------------------------------*/
/* sys_link_freeRTOS.cmd                                                      */
/*                                                                            */
/* 
* Copyright (C) 2009-2018 Texas Instruments Incorporated - www.ti.com  
* 
* 
*  Redistribution and use in source and binary forms, with or without 
*  modification, are permitted provided that the following conditions 
*  are met:
*
*    Redistributions of source code must retain the above copyright 
*    notice, this list of conditions and the following disclaimer.
*
*    Redistributions in binary form must reproduce the above copyright
*    notice, this list of conditions and the following disclaimer in the 
*    documentation and/or other materials provided with the   
*    distribution.
*
*    Neither the name of Texas Instruments Incorporated nor the names of
*    its contributors may be used to endorse or promote products derived
*    from this software without specific prior written permission.
*
*  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 
*  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 
*  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
*  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 
*  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 
*  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 
*  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
*  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
*  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 
*  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 
*  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
*/

/*                                                                            */
/*----------------------------------------------------------------------------*/
/* USER CODE BEGIN (0) */
/* USER CODE END */
/*----------------------------------------------------------------------------*/
/* Linker Settings                                                            */

--retain="*(.intvecs)"

/* USER CODE BEGIN (1) */
/* USER CODE END */

/*----------------------------------------------------------------------------*/
/* Memory Map                                                                 */

MEMORY
{
    VECTORS (X)  : origin=0x00000000 length=0x00000020
    KERNEL  (RX) : origin=0x00000020 length=0x00008000 
    FLASH0  (RX) : origin=0x00008020 length=0x000F7FE0
    STACKS  (RW) : origin=0x08000000 length=0x00001800
    KRAM    (RW) : origin=(0x08000000+0x00001800) length=0x00000800
    RAM     (RW) : origin=(0x08001800+0x00000800) length=(0x0001EB00 - 0x00001800)
    
/* USER CODE BEGIN (2) */

/* USER CODE END */
}

/* USER CODE BEGIN (3) */
/* USER CODE END */

/*----------------------------------------------------------------------------*/
/* Section Configuration                                                      */

SECTIONS
{
    .intvecs : {} > VECTORS
    /* FreeRTOS Kernel in protected region of Flash */
    .kernelTEXT   : {} > KERNEL
    .cinit        : {} > KERNEL
    .pinit        : {} > KERNEL
    .STACK_DATA_svc     : {. += 1024;} > STACKS, RUN_START(StackModeSVC)
    .STACK_DATA_fiq     : {. += 1024;} > STACKS, RUN_START(StackModeFIQ)
    .STACK_DATA_irq     : {. += 1024;} > STACKS, RUN_START(StackModeIRQ)
    .STACK_DATA_abt     : {. += 1024;} > STACKS, RUN_START(StackModeABT)
    .STACK_DATA_und     : {. += 1024;} > STACKS, RUN_START(StackModeUND)
    .STACK_DATA_sys     : {. += 1024;} > STACKS, RUN_START(StackModeSYS)
    /* Rest of code to user mode flash region */
    .text         : {} > FLASH0 
    .const        : {} > FLASH0 
    /* FreeRTOS Kernel data in protected region of RAM */
    .kernelBSS    : {} > KRAM
    .kernelHEAP   : {} > RAM
    .bss          : {} > RAM
    .data         : {} > RAM    
    .sysmem       : {} > RAM
    FEE_TEXT_SECTION : {} > FLASH0
    FEE_CONST_SECTION : {} > FLASH0
    FEE_DATA_SECTION : {} > RAM

/* USER CODE BEGIN (4) */

/* USER CODE END */
}

/* USER CODE BEGIN (5) */
/* USER CODE END */

/*----------------------------------------------------------------------------*/
/* Misc                                                                       */

/* USER CODE BEGIN (6) */
/* USER CODE END */

/*----------------------------------------------------------------------------*/

Any insights or examples would be really helpful!

Thanks & regards,

Ilija

  • Hi Ilija,

    ulFlashStartAddr will get start from the VECTORS start address and that is from the starting address of the flash 0x00000000.

    And ulFlashEndAddr will be at end of the .const section:

    That means the ulFlashStartAddr and ulFlashEndAddr  consists of excpt_vecs, text and const these three sections.

    So, you can try in similar way for your project.

    --
    Thanks & regards,
    Jagadish.

  • Hi Jagadish,

    I’ve updated my linker script to align with the SDL demo application, but I’ve encountered a couple of questions and an issue.

    Could you explain the purpose of the .excpt_vecs section and how it differs from the .intvecs section? I noticed in the SDL demo application’s .map file that .excpt_vecs is listed as uninitialized. Is there a specific reason for this?

    ******************************************************************************
                      TI ARM Linker PC v16.9.6                     
    ******************************************************************************
    >> Linked Wed Oct 02 16:56:38 2024
    
    OUTPUT FILE NAME:   <SL_RM44L920_NoOS.out>
    ENTRY POINT SYMBOL: "_c_int00"  address: 0000ca90
    
    
    MEMORY CONFIGURATION
    
             name            origin    length      used     unused   attr    fill
    ----------------------  --------  ---------  --------  --------  ----  --------
      VECTORS               00000000   00000020  00000020  00000000     X
      FLASH0                00000020   000fffe0  0000ed68  000f1278  R  X
      STACKS                08000000   00001800  00001800  00000000  RW  
      RAM                   08001800   0000ab00  0000059c  0000a564  RW  
      PROFILE               0800c300   00007d00  00000000  00007d00  RW  
      LOG                   08014000   00002000  00002000  00000000  RW    deadbeef 
      FEE                   f0200000   00000064  00000064  00000000  R     deadbeef 
    
    
    SEGMENT ALLOCATION MAP
    
    run origin  load origin   length   init length attrs members
    ----------  ----------- ---------- ----------- ----- -------
    00000000    00000000    0000ed88   0000ed88    r-x
      00000000    00000000    00000020   00000020    r-x .intvecs
      00000020    00000020    0000e2f8   0000e2f8    r-x .text
      0000e318    0000e318    000009b8   000009b8    r-- .const
      0000ecd0    0000ecd0    000000b8   000000b8    r-- .cinit
    08000000    08000000    00001800   00000000    r--
      08000000    08000000    00000400   00000000    r-- .STACK_DATA_abt
      08000400    08000400    00000400   00000000    r-- .STACK_DATA_fiq
      08000800    08000800    00000400   00000000    r-- .STACK_DATA_irq
      08000c00    08000c00    00000400   00000000    r-- .STACK_DATA_svc
      08001000    08001000    00000400   00000000    r-- .STACK_DATA_sys
      08001400    08001400    00000400   00000000    r-- .STACK_DATA_und
    08001800    08001800    0000059c   00000000    rw-
      08001800    08001800    000004fc   00000000    rw- .data
      08001cfc    08001cfc    000000a0   00000000    rw- .bss
    08014000    08014000    00002000   00002000    r--
      08014000    08014000    00002000   00002000    r-- $fill000
    f0200000    f0200000    00000064   00000064    r--
      f0200000    f0200000    00000064   00000064    r-- $fill001
    
    
    SECTION ALLOCATION MAP
    
     output                                  attributes/
    section   page    origin      length       input sections
    --------  ----  ----------  ----------   ----------------
    .excpt_vecs 
    *          0    00000000    00000000     UNINITIALIZED
    
    .intvecs   0    00000000    00000020     
                      00000000    00000020     sys_intvecs.obj (.intvecs)

    In my project, the ulFlashEndAddr is somehow pointing to the FEE_CONST_SECTION (0x0003d938), rather than the .const section as it does in the SDL demo application.

    Here is my .map file for reference.

    ******************************************************************************
                      TI ARM Linker PC v20.2.7                     
    ******************************************************************************
    >> Linked Tue Nov 12 11:05:26 2024
    
    OUTPUT FILE NAME:   <aso_base_project_rm44L920pg.out>
    ENTRY POINT SYMBOL: "_c_int00"  address: 0003594c
    
    
    MEMORY CONFIGURATION
    
             name            origin    length      used     unused   attr    fill
    ----------------------  --------  ---------  --------  --------  ----  --------
      VECTORS               00000000   00000020  00000020  00000000     X
      KERNEL                00000020   00008000  00006910  000016f0  R  X
      FLASH0                00008020   000f7fe0  00035bd8  000c2408  R  X
      STACKS                08000000   00001800  00001800  00000000  RW  
      KRAM                  08001800   00000800  00000140  000006c0  RW  
      RAM                   08002000   0001d300  00006c04  000166fc  RW  
    
    
    SEGMENT ALLOCATION MAP
    
    run origin  load origin   length   init length attrs members
    ----------  ----------- ---------- ----------- ----- -------
    00000000    00000000    00006930   00006930    r-x
      00000000    00000000    00000020   00000020    r-x .intvecs
      00000020    00000020    00006490   00006490    r-x .kernelTEXT
      000064b0    000064b0    00000480   00000480    r-- .cinit
    00008020    00008020    00035bd8   00035bd8    r-x
      00008020    00008020    00031dd8   00031dd8    r-x .text
      00039df8    00039df8    00002f28   00002f28    r-x FEE_TEXT_SECTION
      0003cd20    0003cd20    00000cc8   00000cc8    r-- .const
      0003d9e8    0003d9e8    00000210   00000210    r-- FEE_CONST_SECTION
    08000000    08000000    00001800   00000000    r--
      08000000    08000000    00000400   00000000    r-- .STACK_DATA_abt
      08000400    08000400    00000400   00000000    r-- .STACK_DATA_fiq
      08000800    08000800    00000400   00000000    r-- .STACK_DATA_irq
      08000c00    08000c00    00000400   00000000    r-- .STACK_DATA_svc
      08001000    08001000    00000400   00000000    r-- .STACK_DATA_sys
      08001400    08001400    00000400   00000000    r-- .STACK_DATA_und
    08001800    08001800    00000140   00000000    rw-
      08001800    08001800    00000140   00000000    rw- .kernelBSS
    08002000    08002000    00006c09   00000000    rw-
      08002000    08002000    0000323d   00000000    rw- .bss
      0800523d    0800523d    00003000   00000000    rw- .kernelHEAP
      08008240    08008240    0000088a   00000000    rw- .data
      08008acc    08008acc    0000013d   00000000    rw- FEE_DATA_SECTION
    
    
    SECTION ALLOCATION MAP
    
     output                                  attributes/
    section   page    origin      length       input sections
    --------  ----  ----------  ----------   ----------------
    .intvecs   0    00000000    00000020     
                      00000000    00000020     sys_intvecs.obj (.intvecs)
    
    .excpt_vecs 
    *          0    00000000    00000000     UNINITIALIZED
    

    After modifying the linker script, I’m now encountering an ESM Group 3 error during startup, with the ESM Status Register 1 showing 0x00000040, and ESM Status Register 3 showing 0x00000080. Any idea why this might be happening? Is this got something to do with Flash ECC error or MPU configuration or compiler optimization?

    Any insights you can provide would be much appreciated!

    Thanks & regards,

    Ilija

  • Hi Ilija,

    My understanding is this:

    Usually .intvecs is used to make a table offset for interrupt vectors like (resetEntry, undefEntry etc)

    Once this table is created at section .intvecs  then we are assigning that table to the VECTORS memory which will be start from 0x00000000.

    So, in this way our function pointers for resetEntry, undefEntry etc will get moved to the starting location of the flash.

    Even i don't understand why in SDL library we mentioned excpt_vecs instead of intvecs. And i also i don't see anywhere else in the code we are using excpt_vecs. I will check this with my colleague once whether he have any idea on this.

    --
    Thanks & regards,
    Jagadish.

  • Hi Jagadish,

    I changed my linker command file as show bellow. Is it possible that problem is due to KERNEL section. When i moved ulFlashStartAddr from .intvecs to the .text section there is no ESM Group 3 error.

    Can this be cause of my problem ?

    MEMORY
    {
        VECTORS (X)  : origin=0x00000000 length=0x00000020
        KERNEL  (RX) : origin=0x00000020 length=0x00008000 
        FLASH0  (RX) : origin=0x00008020 length=0x000F7FE0
        STACKS  (RW) : origin=0x08000000 length=0x00001800
        KRAM    (RW) : origin=(0x08000000+0x00001800) length=0x00000800
        RAM     (RW) : origin=(0x08001800+0x00000800) length=(0x0001EB00 - 0x00001800)
        
    /* USER CODE BEGIN (2) */
    
    /* USER CODE END */
    }
    
    /* USER CODE BEGIN (3) */
    /* USER CODE END */
    
    /*----------------------------------------------------------------------------*/
    /* Section Configuration                                                      */
    
    SECTIONS
    {
        .intvecs : {} > VECTORS
        /* FreeRTOS Kernel in protected region of Flash */
        .kernelTEXT   : {} > KERNEL
        .cinit        : {} > KERNEL
        .pinit        : {} > KERNEL
        .STACK_DATA_svc     : {. += 1024;} > STACKS, RUN_START(StackModeSVC)
        .STACK_DATA_fiq     : {. += 1024;} > STACKS, RUN_START(StackModeFIQ)
        .STACK_DATA_irq     : {. += 1024;} > STACKS, RUN_START(StackModeIRQ)
        .STACK_DATA_abt     : {. += 1024;} > STACKS, RUN_START(StackModeABT)
        .STACK_DATA_und     : {. += 1024;} > STACKS, RUN_START(StackModeUND)
        .STACK_DATA_sys     : {. += 1024;} > STACKS, RUN_START(StackModeSYS)
        /* Rest of code to user mode flash region */
        .text         : START ( ulFlashStartAddr ) {} > FLASH0 
        .const        : {} > FLASH0 
        /* FreeRTOS Kernel data in protected region of RAM */
        .kernelBSS    : {} > KRAM
        .kernelHEAP   : {} > RAM
        .bss          : {} > RAM
        .data         : {} > RAM    
        .sysmem       : {} > RAM
        FEE_TEXT_SECTION : {} > FLASH0
        FEE_CONST_SECTION : END ( ulFlashEndAddr ) {} > FLASH0
        FEE_DATA_SECTION : {} > RAM
    
    /* USER CODE BEGIN (4) */
    
    /* USER CODE END */
    }

    I changed .excpt_vecs to the .intvecs.

    Thanks & regards,

    Ilija.

  • Hi Ilija,

    I changed my linker command file as show bellow. Is it possible that problem is due to KERNEL section. When i moved ulFlashStartAddr from .intvecs to the .text section there is no ESM Group 3 error.

    Can this be cause of my problem ?

    Could be a kernel because i don't see kernel in SDL demo project because it is not built on FreeRTOS and there are no issues in CRC calculations.

    --
    Thanks & regards,
    Jagadish.

  • Hi Jagadish,

    When calculating the CRC for flash memory to verify integrity, should the VECTORS section be included as part of the calculation, or can it be excluded without impacting the reliability of the CRC check?

    Thanks & regards,

    Ilija.

  • Hi Ilija,

    I would say it is just an application requirement.

    But in this freeRTOS application case the kernel looks like in between the VECTORS and text sections. May be in this case it would be difficult to include VECTORS and text sections only without kernel and we already saw a issue in including the kernel.

    Maybe it would be better to exclude the VECTORS here otherwise we might calculate two parts of CRC independently for VECTORS and text.

    --
    Thanks & regards,
    Jagadish.