Loading...
 

Zephyr project on STM32

   Zephyr Workbench, a VSCode extension to manage Zephyr on STM32.
It enables users to easily create, develop, and debug Zephyr applications.
Main features:
  • Install host dependencies.
  • Import toolchain and SDK.
  • Create, configure, build and manage apps.
  • Debug STM32.
You can directly download it from the VSCode marketplace
For more details, visit the Zephyr Workbench

System Workbench for STM32


Bootloader Erased when Application is programmed

If you change your linker configuration file (normally called LinkerScript.ld) to omit from the ROM memory section the portion of program space used by your bootloader, the ELF loader will not erase or overwrite those portions of the ROM/FLASH that have been excluded.

Here’s what the MEMORY defintion inside LinkerScript.ld looks like by default for the STM32F091RC:
(128K FLASH, 32K RAM)

MEMORY
{
  RAM (rwx)     : ORIGIN = 0x20000000, LENGTH = 32K
  ROM (rx)      : ORIGIN = 0x08000000, LENGTH = 128K
}


The modified version below shows what you’d need to do if you wanted to reserve the first 32K of program FLASH space for a bootloader:

MEMORY
{
  RAM (rwx)     : ORIGIN = 0x20000000, LENGTH = 32K
  ROM (rx)      : ORIGIN = 0x08008000, LENGTH = 96K
}


Note how the ROM start address was increased by 0x8000 from 0x0800_0000 to 0x0800_8000, and the LENGTH reduced from 128K to 96K.

When you do a debug or run, or use the project explorer right-click context menu “Target” option to program your code when built using the modified MEMORY definition shown above, the first 32K of program FLASH should be left unchanged.

At the section level, it is possible to omit parts from being loaded/flashed by using the NOLOAD modifier in the section declaration in the linker config file. The example below shows what I did to allocate a 2K page of program FLASH for non-volatile parameter variable storage:

MEMORY
{
  RAM (rwx)     : ORIGIN = 0x20000000, LENGTH = 32K
  ROM (rx)      : ORIGIN = 0x08000000, LENGTH = 126K
  P_FLASH (rw)  : ORIGIN = 0x0801F800, LENGTH = 2K
}

. . . 

 /*
  Non-volatile parameter data in FLASH
  Note - from GNU toolchain documentation:
  The (NOLOAD) directive will mark a section to not be loaded at run time.
  The linker will process the section normally, but will mark it so that 
  a program loader will not load it into memory.
  */ 

  .param_flash (NOLOAD) :
  {
    . = ALIGN(0x800);
    __param_flash_start = .;
    *(.param_flash)
    *(.param_flash*)
    . = ALIGN(4);
    __param_flash_end = .;
  } >P_FLASH


In the C source, you’d declare a variable to be located in this section like this:

param_t param_flash __attribute__ ((section (".param_flash"),used));


I won’t go into more detail on how to create NV variable storage here... there’s more to it than what I’ve shown here. I bring it up only to demonstrate how one can use the NOLOAD section modifier to instruct the linker/loader to exclude otherwise ROMable sections from a program load.

 

Newest Forum Posts

  1. Монтаж камина с грилем в Москве - установка и барбекю by KpddomErorb, 2025-05-10 18:28
  2. SPI on Nucleo_STMH533RE by royjamil, 2025-05-04 20:13
  3. SPI on Nucleo_STMH533RE by higginsa1, 2025-03-25 07:37
  4. SPI on Nucleo_STMH533RE by royjamil, 2025-03-23 11:31
  5. SPI on Nucleo_STMH533RE by higginsa1, 2025-03-23 09:33
  6. Configuring DMA for ADC in SW? by sam.hodgson, 2025-03-04 12:58
  7. Build a project in "release" mode by info@creosrl.it, 2025-02-20 18:12
  8. Build a project in "release" mode by info@creosrl.it, 2025-02-20 17:05
  9. Build a project in "release" mode by tang, 2025-02-20 10:36
  10. Build a project in "release" mode by info@creosrl.it, 2025-02-19 17:35

Last-Modified Blogs