[SOLVED] How to get access to the content of the memory map inside the application

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] How to get access to the content of the memory map inside the application

    Hi ,
    I'm working on Cortex M3/4 wit SES and I should have access to the real image size, i.e. start address and end address.
    Start address will almost always (except on an applications with booloader for example) 0x8000000, the end depends on the length of the application.

    Formerly in GNU LD this sequence was sufficient in the linker file:

    Source Code

    1. .text :
    2. {
    3. __StartOfImage = .;
    4. _ISR_Vector = .; /* this symbol is needed to give us a chance to remap the program */
    6. /* Startup code */
    7. KEEP(*(.isr_vector))
    8. /* Code section */
    9. *(.text*)
    11. KEEP(*(.init))
    12. KEEP(*(.fini))
    14. /* .ctors */
    15. *crtbegin.o(.ctors)
    16. *crtbegin?.o(.ctors)
    17. *(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors)
    18. *(SORT(.ctors.*))
    19. *(.ctors)
    21. /* .dtors */
    22. *crtbegin.o(.dtors)
    23. *crtbegin?.o(.dtors)
    24. *(EXCLUDE_FILE(*crtend?.o *crtend.o) .dtors)
    25. *(SORT(.dtors.*))
    26. *(.dtors)
    28. /* Rodata section (constants, strincs, ...) */
    29. *(.rodata*)
    31. KEEP(*(.eh_frame*))
    32. __EndofImage = .;
    33. } > FLASH
    Display All

    where __StartOfImage contained the start address and __EndOfImage the end address respectivly, which both were accessible from the application via a simple variable access.

    How can I do this with the Segger linker?

    73 de Kai DL1GJJ

  • The purpose of such an action is usually a runtime check across the whole application, comparing it with a precalculated checksum stored inside the image.
    I have done this for other MCUs (proprietary Fujitsu architectue), not Cortex M.
    So I can give only general advice.

    But the idea is to modify the linker map appropriately.
    Check the linker script file (*.ICF) for the highest section of interest for you.
    Split off a separate section with the same parameters as the preceeding one (or similiar) at the end.
    In the code, place a specific (initialized) variable in this section.
    The application image should now range from the start up the the address of the given specific variable.

    Details depend on the toolchain, especially the linker and linker script file.

  • _frank_ wrote:

    The purpose of such an action is usually a runtime check across the whole application, comparing it with a precalculated checksum stored inside the image.
    Hello, Frank,
    thanks for the reply.
    The purpose in my case is to create a set of information of the application and provide this to a bootloader and vice versa. This information block shall contain the start address, the end address and other information. All in all the worked properly with the linker files of the gnu linker like posted above.
    But with newer projects I intend to use segger compiler and linker.

    There I found no way to declare external accessible variables.
    I tried out your solution but I could not create an overlaying section.

    _frank_ wrote:

    Details depend on the toolchain, especially the linker and linker script file.
    I couldn't found anything similar in the documentation of the linker or I'm silly stupid to read.

    73 de Kai DL1GJJ

  • > The purpose in my case is to create a set of information of the application and provide this to a bootloader and vice versa. This information block shall contain the start address, the end address and other information.
    That is the purpose in my case as well.
    The application is preceeded by a header containing this data, including an embedded checksum.
    This checksum is first checked by the bootloader during the update. The BL calculates and compares the checksum before executing an application.
    At runtime, a kind of background task continuously checks the consistency, including code and configuration data (SIL2 /PL.d).

    Though as said, the actual implementation depends very much upon the memory map of the target device, and the toolchain of course.

    I would suggest to look at *.ICF files coming with SES, and modifying it according to you needs.
    They even provide links to documentation at the Segger site (taken from an ICF which is part of one of my projects:

    Source Code

    1. Literature:
    2. [1] SEGGER Linker User Guide (https://www.segger.com/doc/UM20005_Linker.html)
    3. [2] SEGGER Linker Section Placement (https://wiki.segger.com/SEGGER_Linker_Script_Files)
    4. */
    The linker script is part of the individual project, usually as "$(ProjectDir)/*.icf".
    (Options->Linker->Linker Script File).

  • Hello,

    Thank you for your inquiry.

    How to use linker generated symbols is described here:
    wiki.segger.com/How_to_use_Linker-generated_symbols

    How to use them for a bootloader with e.g. a integrity check which is natively supported by our Linker is explained here with an example:
    wiki.segger.com/Integrity_chec…_Studio_and_SEGGER_Linker


    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • SEGGER - Nino wrote:

    ...

    How to use linker generated symbols is described here:
    wiki.segger.com/How_to_use_Linker-generated_symbols

    How to use them for a bootloader with e.g. a integrity check which is natively supported by our Linker is explained here with an example:
    wiki.segger.com/Integrity_chec…_Studio_and_SEGGER_Linker
    ...
    Hello, Nino,
    this is exactly, what I was looking for, tnx for the link.
    The integrity check sounds interesting too, I'll have a look at it.


    73 de Kai DL1GJJ

    The post was edited 2 times, last by DL1GJJ ().