How to prevent overwriting of user data inside flash when flashing?

[-_]

Hello everyone,

I want to store configuration data in a flash section that should be retained after updating the code on the controller / flashing a new program. Is this possible using the CubeIDE? If yes, how is it done. If no, can this be done otherwise? As far as I can tell, when downloading the code onto the microcontroller, the whole flash storage will be erased.

Thanks for your help!

[Andrew Neil]

CubeIDE will only erase as much flash as it needs for the programming:

https://community.st.com/t5/stm32cubeide-mcus/partial-or-full-chip-erase-before-programming/m-p/734869/highlight/true#M31829

So just make sure that your "user data" is outside that range

[-_]

My observation sadly does not match with this description. I'm using a STM32H753 Nucleo board. I modified the linker script as follows:

MEMORY
{
RAM_D1 (xrw)      : ORIGIN = 0x20000000, LENGTH = 128K
DTCMRAM (xrw)      : ORIGIN = 0x24000000, LENGTH = 512K
RAM_D2 (xrw)      : ORIGIN = 0x30000000, LENGTH = 288K
RAM_D3 (xrw)      : ORIGIN = 0x38000000, LENGTH = 64K
ITCMRAM (xrw)      : ORIGIN = 0x00000000, LENGTH = 64K
FLASH (rx)      : ORIGIN = 0x8000000, LENGTH = 1920K
USER_FLASH(rw)  : ORIGIN = 0x81E0000, LENGTH = 128K
}

 So, I reserved Bank 2 Sector 7 as my own flash memory. Furthermore, I declared it as NOLOAD:

.user_flash(NOLOAD) : 
 { 
 *(.user_flash*); 
 } > USER_FLASH

But when trying to debug the program using the CubeIDE, the data from these sections is overwritten with 224 bytes of zeros followed by 228 Bytes of ones. (I might have mixed up the amount of zeros and ones here)

[Pavel A.]

> CubeIDE will only erase as much flash as it needs for the programming:

But it erases all sectors occupied by the new program and does not restore previous data after the last byte of the programmed data. If your user data is stored in the last sector of the image after the program, make your own tool for updating.

[-_]

---

@Pavel A. wrote:

[...] it erases all sectors occupied by the new program [...]

---

Thanks for your reply. Does the USER_FLASH section count as "occupied by the program"?

[Pavel A.]

Everything contained in the resulting program counts as occupied by the program. Check the linker map file if not sure.

[Tesla DeLorean]

Perhaps use OBJDUMP to establish WHAT in the .ELF file is being put into a NOBITS section.

You can look at the .MAP too, but I tend to use the .ELF as the arbiter of what exactly the linked object is telling the programmer/loader to do.

[-_]

Using objdump -h yields:

➜  Debug objdump -h FLASH_EraseProgram.elf

FLASH_EraseProgram.elf:     file format elf32-little

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .isr_vector   00000298  08000000  08000000  00001000  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .text         000026e4  08000298  08000298  00001298  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .rodata       00000018  0800297c  0800297c  0000397c  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .ARM.extab    00000000  08002994  08002994  00004040  2**0
                  CONTENTS
  4 .ARM          00000000  08002994  08002994  00004040  2**0
                  CONTENTS
  5 .preinit_array 00000000  08002994  08002994  00004040  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  6 .init_array   00000004  08002994  08002994  00003994  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .fini_array   00000004  08002998  08002998  00003998  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .data         00000040  20000000  0800299c  00004000  2**3
                  CONTENTS, ALLOC, LOAD, DATA
  9 .bss          00000074  20000040  080029dc  00004040  2**3
                  ALLOC
 10 ._user_heap_stack 00000604  200000b4  080029dc  000040b4  2**0
                  ALLOC
 11 .ARM.attributes 0000002e  00000000  00000000  00004040  2**0
                  CONTENTS, READONLY
 12 .debug_info   00008ada  00000000  00000000  0000406e  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 13 .debug_abbrev 00001774  00000000  00000000  0000cb48  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 14 .debug_aranges 000006c8  00000000  00000000  0000e2c0  2**3
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 15 .debug_rnglists 00000504  00000000  00000000  0000e988  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 16 .debug_macro  00034dc7  00000000  00000000  0000ee8c  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 17 .debug_line   00009059  00000000  00000000  00043c53  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 18 .debug_str    00152fe1  00000000  00000000  0004ccac  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 19 .comment      00000043  00000000  00000000  0019fc8d  2**0
                  CONTENTS, READONLY
 20 .debug_frame  00001a1c  00000000  00000000  0019fcd0  2**2
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 21 .debug_line_str 000000ab  00000000  00000000  001a16ec  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS

readelf -S returns:

➜  Debug readelf -S FLASH_EraseProgram.elf
There are 26 section headers, starting at offset 0x1a43e4:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .isr_vector       PROGBITS        08000000 001000 000298 00   A  0   0  1
  [ 2] .text             PROGBITS        08000298 001298 0026e4 00  AX  0   0  4
  [ 3] .rodata           PROGBITS        0800297c 00397c 000018 00   A  0   0  4
  [ 4] .ARM.extab        PROGBITS        08002994 004040 000000 00   W  0   0  1
  [ 5] .ARM              PROGBITS        08002994 004040 000000 00   W  0   0  1
  [ 6] .preinit_array    PREINIT_ARRAY   08002994 004040 000000 04  WA  0   0  1
  [ 7] .init_array       INIT_ARRAY      08002994 003994 000004 04   A  0   0  4
  [ 8] .fini_array       FINI_ARRAY      08002998 003998 000004 04   A  0   0  4
  [ 9] .data             PROGBITS        20000000 004000 000040 00  WA  0   0  8
  [10] .bss              NOBITS          20000040 004040 000074 00  WA  0   0  8
  [11] ._user_heap_stack NOBITS          200000b4 0040b4 000604 00  WA  0   0  1
  [12] .ARM.attributes   ARM_ATTRIBUTES  00000000 004040 00002e 00      0   0  1
  [13] .debug_info       PROGBITS        00000000 00406e 008ada 00      0   0  1
  [14] .debug_abbrev     PROGBITS        00000000 00cb48 001774 00      0   0  1
  [15] .debug_aranges    PROGBITS        00000000 00e2c0 0006c8 00      0   0  8
  [16] .debug_rnglists   PROGBITS        00000000 00e988 000504 00      0   0  1
  [17] .debug_macro      PROGBITS        00000000 00ee8c 034dc7 00      0   0  1
  [18] .debug_line       PROGBITS        00000000 043c53 009059 00      0   0  1
  [19] .debug_str        PROGBITS        00000000 04ccac 152fe1 01  MS  0   0  1
  [20] .comment          PROGBITS        00000000 19fc8d 000043 01  MS  0   0  1
  [21] .debug_frame      PROGBITS        00000000 19fcd0 001a1c 00      0   0  4
  [22] .debug_line_str   PROGBITS        00000000 1a16ec 0000ab 01  MS  0   0  1
  [23] .symtab           SYMTAB          00000000 1a1798 0019c0 10     24 198  4
  [24] .strtab           STRTAB          00000000 1a3158 00116e 00      0   0  1
  [25] .shstrtab         STRTAB          00000000 1a42c6 00011c 00      0   0  1

I can't find any part of the USER_FLASH memory range in any of those outputs.