Loading...
 

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

System Workbench for STM32


Locating data in a specific ROM section

France

Hi Sylvain,

First in your C code, I don’t understand why you created your constant variable as “volatile const”; just creating it as “const” will place it in the “rodata” section that will go in flash automatically.

The “volatile const” idiom should be used for modeling read-only device registers, that you can’t write (so the const) but may change by themselves (so the volatile); this is obviously not what you want here, as you want this data to be really constant and placed in ROM.

Also when including code in a post, you should use the CODE plugin to format it correctly, and avoid the braces and quare braces to “disapear” from the output: use
{CODE()}your C code with [] and {}{CODE}
.


Anyway, in the fragment below, taken from your linker script:

._const_data :
{
    . = ALIGN(4);
    *(.rodata)
    *(.rodata*)
    *(.text) /* .text sections (code) */
    *(.text*) /* .text* sections (code) */
} >ROM_Data
  • You declare an output section, in your executable linker file, named ._const_data
  • This section will contain all .rodata, .rodata.xxx, .text and .text.xxx sections of your input files (at least if they were not already placed in a precedently defined output section)
  • You asked this output section to be placed in the ROM_data part of your flash


This does not work as you do not say where to place the ._const_data sections of your input files. The confusion you make here was between the names of sections as found in the input files and the names given to sections in the generated executable file.

The simplest to place some constant data in flash would be, if you don’t want to explicitly partition your flash array, to start from the standard linker script file and just add two lines reading

*(._const_data)         /* .rodata sections (constants, strings, etc.) */
    *(._const_data*)        /* .rodata* sections (constants, strings, etc.) */

in the .rodata output section; the only inconvenient is that your constant data will be interleaved with compiler-generated constant data.

However, any variable declared “const” at the global (or static) level of your source file is already, by default, placed in the .rodata section, so in fact this is even useless if you can accept your constant data to be interleaved with other constant data.

If that interleaving bothers you, add a full new output section by:

._const_data :
  {
    . = ALIGN(4);
    *(._const_data)         /* .rodata sections (constants, strings, etc.) */
    *(._const_data*)        /* .rodata* sections (constants, strings, etc.) */
  . = ALIGN(4);
  } >ROM

Then all your own constant data will be located together in memory.

Creating a specific ROM section is only needed if you want to control the amount of flash devoted to your own const data and to the generated code and litteral data.

Bernard