Save data in Flash of STM32 through Code 1, Accessing same data with Code 2

[Lucifer37]

Hi,

I am working on a project that store the Configuration data of one device, It needs to be stored in specific section

static unsigned char myBuffer[4] __attribute__((section (".m_data_20000000"))) { 11, 22, 33, 44};

with this command I'm able to store it in Program-1 

linker script of program-1

.m_data_20000000 :
{
. = ALIGN(4);
KEEP (*(.m_data_20000000*))
. = ALIGN(4);
} >FLASH

I have tried NOLOAD NOINIT it is not working...........what changes need to do in program-2

But now I want the stored myBuffer[4] data from Flash of stm32 which is stored previously by program-1, without erasing I want access of myBuffer[4] with program-2?

What changes I need to do in IAR and STM32Cube IDE for telling them not erase that section, I want access, what type of variable I need to declare in program-2 it is pointer or extern..........

Please Help me.... 

[Tesla DeLorean]

Aren't the Erasable sectors larger than that?

You need to pick blocks which are distinct and uninvolved with your code foot prints.

And use Update methods that don't trash uninvolved sectors. If you provide the methods, you can control the experience..

[Andrew Neil]

---

@Lucifer37 wrote:

STM32 Flash
-------------------
| source code | 0x08000000
|                      |
|                      |
| code End      |
|                      |
|-------------------|0x0800F000
| Config data   |
-------------------|0x080FFFFF

---

0x800F000 falls in the middle of a Sector:

https://www.st.com/resource/en/reference_manual/rm0399-stm32h745755-and-stm32h747757-advanced-armbased-32bit-mcus-stmicroelectronics.pdf#page=159

[Lucifer37]

THANKS FOR ALL YOUR REPLIES, @Andrew Neil @Tesla DeLorean 

Just help me understand this :

MEMORY

{

RAM_D1 (xrw) : ORIGIN = 0x24000000, LENGTH = 512K

FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 512K /* Memory is divided. Actual start is 0x08000000 and actual length is 1024K */

CONFIG_DATA : ORIGIN = 0x080E0000, LENGTH = 128K

DTCMRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K

RAM_D2 (xrw) : ORIGIN = 0x30000000, LENGTH = 288K

RAM_D3 (xrw) : ORIGIN = 0x38000000, LENGTH = 64K

ITCMRAM (xrw) : ORIGIN = 0x00000000, LENGTH = 64K

}

.....

.....

.configdata :

{

. = ALIGN(4);

*(.configdata*)

. = ALIGN(4);

} >CONFIG_DATA

with this I'm able stop CONFIG_DATA from Erasing/untouched, or I should use NOLOAD/NOINIT ?

[Andrew Neil]

See the Posting Tips for how to post "formatted" text - with & without C syntax highlighting:

https://community.st.com/t5/community-guidelines/how-to-write-your-question-to-maximize-your-chances-to-find-a/tac-p/725146/highlight/true#M54

MEMORY
{
   RAM_D1 (xrw)  : ORIGIN = 0x24000000, LENGTH = 512K
   FLASH (rx)    : ORIGIN = 0x08000000, LENGTH = 512K /* Memory is divided. Actual start is 0x08000000 and actual length is 1024K */
   CONFIG_DATA   : ORIGIN = 0x080E0000, LENGTH = 128K
   DTCMRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
   RAM_D2 (xrw)  : ORIGIN = 0x30000000, LENGTH = 288K
   RAM_D3 (xrw)  : ORIGIN = 0x38000000, LENGTH = 64K
   ITCMRAM (xrw) : ORIGIN = 0x00000000, LENGTH = 64K
}

:
:

.configdata :
{
   . = ALIGN(4);
   *(.configdata*)
   . = ALIGN(4);
} >CONFIG_DATA

[Andrew Neil]

Sorry - hit 'Post' too soon!

I don't know exactly how CubeIDE decides what memory is its to erase.

As @Tesla DeLorean also mentioned, one way is to simply manage it yourself to ensure that your data is beyond what gets used by the code.

I think that just reducing the FLASH size in the MEMORY section would do that?

eg,

MEMORY
{
   RAM_D1 (xrw)  : ORIGIN = 0x24000000, LENGTH = 512K
   FLASH (rx)    : ORIGIN = 0x08000000, LENGTH = 384K   

 So that the tools "think" that there is 128K less than is actually present - and, thus, will never try to erase it.

You then manage placing the data in that top 128K yourself - as previously described...

[Tesla DeLorean]

I don't push configuration memory in via the tools.

Like I said, array this stuff in a structure so there's a common understanding of what's in there. Perhaps provide a sequence number, and a checksum/crc to confirm the validity of intact frames, have a version number if you plan on evolving what's in there.

With a structure you can journal copies across the FLASH page, and avoid excessive and slow erase-write cycles causing wear.

Have your application scan the configuration space for most recent and valid data, and be prepared to write in and use functional defaults if it is missing. Or provide a means to push data in at final test / calibration.

There's perhaps OTP for stuff that never changes, say MAC addresses or keys.

Each device also has a 96-bit Unique ID that ST assigns during wafer production and test.