Do not erase a sector on subsequent SW uploads

[LaoMa]

Hello, I'm using a STM32F103 and my code needs to save a few parameters from calibration activities in factory in the FLASH. I have successfully configured the last sector and I use it.

Then, what I'd like is:

FLASH the STM32 with the whole SW the 1st time

calibrate the board and save the parameters in the last sector of the FLASH

Subsequent uploads of updated version of SW should not erase and overwrite that sector, but it should be r/w accessible from inside the application.

May it be possible using the OPTION BYTES or any other way?

Thanks a lot

Maurizio

[TDK]

There shouldn't be any issues with this scheme. Generally, flashing will only erase the sectors it needs to erase unless you choose to erase the entire chip. Flash pages are readable/writeable with the limitation that you must erase before writing and can only erase the full page.

Option bytes can't be used to store information since they're used for other things.

[LaoMa]

Thanks....

but when I upload the FLASH, the programmer erases pages 0-51 and 63, in example.

That's correct the first time, but the 2nd time I don't want to erase the page 63.

I know that I can ever prepare 2 profiles, one for 1st time and another for subsequent updates.... but it cannot work for a clear maintenance of the code.

How I can disable the page 63 (ore some more) to be erased/rewritten ONLY for SW uploads after the 1st one?

Or I have to change code and never allow to access the page 63 using the linker (.Id file)? some doubts how to declare the data in the sector 63 to be accessible :worried_face:

Thanks

[TDK]

The program can't differentiate between first and subsequent programming. Remove page 63 from your linker and manage it manually. Using pointers to structures is one method. If the data is all 0xFF, you can assume it needs initialized for the first time.

[LaoMa]

Thx, TDK.

Forgive me, but I define a sector in the linker than I initialize those variable using a const uint16_t in this way:

This's the code

// this section set the initial factors in the firsts location of the emulated EEPROM. section address is set in the linker

__attribute__((section(".eeprom")))        const uint16_t EE_Start[] = { ((0) << 😎 + 30,

950, 1000, 1000 };

const uint8_t EE_length = sizeof(EE_Start) / sizeof(EE_Start[0]); //

and this's the linker

/* Memories definition */

MEMORY

{

 RAM  (xrw)  : ORIGIN = 0x20000000,  LENGTH = 20K

 FLASH  (rx)  : ORIGIN = 0x8000000,  LENGTH = 64K-1K

 EEPROM (rx) :ORIGIN = 0x800FC00,  LENGTH = 1K /* added by LaoMa */

}

....

 /* additional segment for EEProm Emulation */

 .eeprom :

 {

  . = ALIGN(4);

 *(.eeprom);

 } > EEPROM

Then, you are suggesting to remove those code and linker sections and go ahead using a pointer for EEprom start address, compare *pointer to 0xFFFF and acting in consequence , aren't you?

In this way, the .hex file last address fells before page 63, that page shouldn't be ever erased from programmer... and this is true with STM32CubeProgrammer. But what with other programming SW? i.e. from KEIL?

Thanks again

Maurizio

[TDK]

> Then, you are suggesting to remove those code and linker sections and go ahead using a pointer for EEprom start address, compare *pointer to 0xFFFF and acting in consequence , aren't you?

Yes.

Your code currently defines data in this section, so the generated ELF or HEX file will contain that data and the programmer will try to write it.

> In this way, the .hex file last address fells before page 63, that page shouldn't be ever erased from programmer... and this is true with STM32CubeProgrammer. But what with other programming SW? i.e. from KEIL?

By default, yes. Not sure on Keil. I assume it is configurable there as well.