Linking and memory issues for STM32F1 microcontrollers

Question

Let us look at the STM32F103 linker script:

/* Entry Point */
ENTRY(Reset_Handler)

/* Highest address of the user mode stack */
_estack = 0x20005000;    /* End of 20K RAM */

/* Generate a link error if heap and stack don't fit into RAM */
_Min_Heap_Size = 0;      /* Required amount of heap  */
_Min_Stack_Size = 0x100; /* Required amount of stack */

/* Specify the memory areas */
MEMORY
{
  FLASH (rx)      : ORIGIN = 0x08000000, LENGTH = 128K
  RAM (xrw)       : ORIGIN = 0x20000000, LENGTH = 20K
  MEMORY_B1 (rx)  : ORIGIN = 0x60000000, LENGTH = 0K
}

/* Define output sections */
SECTIONS
{
  /* The startup code goes first into FLASH */
  .isr_vector :
  {
    . = ALIGN(4);
    KEEP(*(.isr_vector)) /* Startup code */
    . = ALIGN(4);
  } >FLASH

  /* The program code and other data goes into FLASH */
  .text :
  {
    . = ALIGN(4);
    *(.text)           /* .text sections (code) */
    *(.text*)          /* .text* sections (code) */
    *(.rodata)         /* .rodata sections (constants, strings, etc.) */
    *(.rodata*)        /* .rodata* sections (constants, strings, etc.) */
    *(.glue_7)         /* Glue arm to thumb code */
    *(.glue_7t)        /* Glue thumb to arm code */

    KEEP (*(.init))
    KEEP (*(.fini))

    . = ALIGN(4);
    _etext = .;        /* Define a global symbols at end of code */
  } >FLASH


   .ARM.extab   : { *(.ARM.extab* .gnu.linkonce.armextab.*) } >FLASH
    .ARM : {
    __exidx_start = .;
      *(.ARM.exidx*)
      __exidx_end = .;
    } >FLASH

  .ARM.attributes : { *(.ARM.attributes) } > FLASH

  .preinit_array     :
  {
    PROVIDE_HIDDEN (__preinit_array_start = .);
    KEEP (*(.preinit_array*))
    PROVIDE_HIDDEN (__preinit_array_end = .);
  } >FLASH
  .init_array :
  {
    PROVIDE_HIDDEN (__init_array_start = .);
    KEEP (*(SORT(.init_array.*)))
    KEEP (*(.init_array*))
    PROVIDE_HIDDEN (__init_array_end = .);
  } >FLASH
  .fini_array :
  {
    PROVIDE_HIDDEN (__fini_array_start = .);
    KEEP (*(.fini_array*))
    KEEP (*(SORT(.fini_array.*)))
    PROVIDE_HIDDEN (__fini_array_end = .);
  } >FLASH

  /* Used by the startup to initialize data */
  _sidata = .;

  /* Initialized data sections goes into RAM, load LMA copy after code */
  .data : AT ( _sidata )
  {
    . = ALIGN(4);
    _sdata = .;        /* Create a global symbol at data start */
    *(.data)           /* .data sections */
    *(.data*)          /* .data* sections */

    . = ALIGN(4);
    _edata = .;        /* Define a global symbol at data end */
  } >RAM

  /* Uninitialized data section */
  . = ALIGN(4);
  .bss :
  {
    /* This is used by the startup in order to initialize the .bss secion */
    _sbss = .;         /* Define a global symbol at BSS start */
    __bss_start__ = _sbss;
    *(.bss)
    *(.bss*)
    *(COMMON)

    . = ALIGN(4);
    _ebss = .;         /* Define a global symbol at BSS end */
    __bss_end__ = _ebss;
  } >RAM

  PROVIDE ( end = _ebss );
  PROVIDE ( _end = _ebss );

  /* User_heap_stack section, used to check that there is enough RAM left */
  ._user_heap_stack :
  {
    . = ALIGN(4);
    . = . + _Min_Heap_Size;
    . = . + _Min_Stack_Size;
    . = ALIGN(4);
  } >RAM

  /* MEMORY_bank1 section, code must be located here explicitly            */
  /* Example: extern int foo(void) __attribute__ ((section (".mb1text"))); */
  .memory_b1_text :
  {
    *(.mb1text)        /* .mb1text sections (code) */
    *(.mb1text*)       /* .mb1text* sections (code)  */
    *(.mb1rodata)      /* read-only data (constants) */
    *(.mb1rodata*)
  } >MEMORY_B1

  /* Remove information from the standard libraries */
  /DISCARD/ :
  {
    libc.a ( * )
    libm.a ( * )
    libgcc.a ( * )
  }
}

I can see that ISR vectors are placed in flash, so if the program needs to call address stored in some vector, it will read from flash memory.

First question: How does hardware not make difference between reading from RAM and flash? And why do I then need special registers to write into or read from flash memory in code and can not just explicitly write or read from its addresses?

Second question is that about how much is it slower to read from flash than from RAM? And if I know what function is used the most in my code then am I able to move it to RAM section to crucially speed up it execution? I believe MEMORY_B1 in this script is made especially for this purpose.

Third question: How can we place anything in MEMORY_B1 if it has a length of 0?

And the last question: If I create an additional section in flash memory then can I create some simple analogue of virtual memory? I think answer to this question depends on the first one.

Answer 1

1. Hardware does not care, because both memories (and actually anything else) is mapped in the common address space. However this does not mean you can easily write flash memory to treat it as RAM, as this is slow and can quickly damage the memory (it has a typical write endurance of 100k cycles). Moreover, it can be erased only in full pages (which can be as big as 128 kB for some STM32 chips), which really makes it problematic to use as a substitute for RAM.

2. The difference in speed is negligible. Running your code from RAM on ARM Cortex-M microcontrollers will be slower than you expect, as RAM is connected to different bus (meant for data) and using it for code execution requires use of a slower "interconnect".

3. You cannot. If you would want to place something there, the size of memory would have to be increased (and size of "normal RAM" - decreased).

4. Generally you could do that, but it would be extremely slow and you would quickly damage the flash.

Answer 2

1/2. Is does not on an STM32F1. Only with core speeds over 100 Mhz the flash prefetch and cache miss will cost you. Even this chip has cache and prefetch. With this core there might be a negligible small profit if you put the vector table in RAM in some special cases.

There could however be a hardware limit that applies to the access width used. But this flash is not affected by that.

3. Yes you certainly can. You'd could put a filesystem in it. But you the temperature range in which is can reliably write the flash is limited. And, since there is only one bank of flash, all activity halts until the erase/flash has been succeeded. Unless code is running from RAM. Two extra caveats are that flash programming/erasing can take milliseconds, and you'd have to take into account the page erases of 2 kB each, but all flash controllers have to.

If you're in need of extra RAM, put some SPI FRAM on your board.