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?

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

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

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/*----------------------------------------------------------------------------*/
/* 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
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

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?

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    ******************************************************************************
    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
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    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.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    ******************************************************************************
    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
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    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 ?

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    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
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    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.