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.... 

[Andrew Neil]

So you want to:

1. Some code in the STM32 writes data to flash.
2. You re-program the STM32 with different code.
3. You want that new code to be able to read the data stored at (1).

Yes?

 

---

@Lucifer37 wrote:

I have tried NOLOAD NOINIT it is not working... 

---

What, exactly, is "not working" ?

• The data isn't stored at all?
• The data is stored in the wrong place?
• The data gets erased during the re-programming?
• The data survives re-programming, but the new code doesn't read it (properly)?
• other??

STM32Cube IDE shouldn't erase more of the flash than it needs to - so, for the data to persist, you just have to make sure that it's outside the area that gets erased during programming.

You'd need to ask IAR what their tool does - but there should certainly be a way to configure this.

[Lucifer37]

These problems I'm facing, how to access data through re-programming and it's getting erased how to stop it

should I use it as extern or coping through section address?

• The data gets erased during the re-programming?
• The data survives re-programming, but the new code doesn't read it (properly)?

How to do it in STM IDE and IAR please send me recourses

[Andrew Neil]

I answered the question about erasing.

One way to easily access it is to just have it at a fixed address, and access that address directly.

You haven't said what STM32 you're using, but that's exactly how the STM32F0 EEPROM emulation does it:

 

/* EEPROM start address in Flash */
#define EEPROM_START_ADDRESS ((uint32_t)0x0800F800) /* EEPROM emulation start address:
 * Penultimate 1K page of a 64K flash
 */

 

https://community.st.com/t5/stm32-mcus-embedded-software/x-cube-eeprom-not-for-stm32f0/m-p/674820

 

PS:

Rather than use a Magic Number, the stm32f030x8.h file defines FLASH_BANK1_END...

[Lucifer37]

I'm using STM32H745

[Andrew Neil]

https://www.st.com/resource/en/application_note/an5342--how-to-use-error-correction-code-ecc-management-for-internal-memories-protection-on-stm32-mcus-stmicroelectronics.pdf#page=11

https://www.st.com/resource/en/application_note/an4894-how-to-use-eeprom-emulation-on-stm32-mcus-stmicroelectronics.pdf

So that's X-CUBE-EEPROM: 

https://www.st.com/en/embedded-software/x-cube-eeprom.html

https://community.st.com/t5/stm32-mcus/porting-and-using-x-cube-eeprom-with-any-stm32/ta-p/570539

 

[Lucifer37]

Hi Andrew Neil,

I'm using STM32H745ZIT3.....I don't know you understood my requirement or not, This EEOPROM Emulation seems

different concept, it uses different approach like when power is off we able to access same data from same code

when re-program or dump new program-2 it will erase that config data

I'm using Linker script to store config data in specific region.......

Program-1
--------------------
| config data   |
| store @        |
| 0x0800F000 |
|                      |
|linker can do |
|define sec     |
|                      |
---------------

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

Program-2
--------------------
|Access the    |
| config data   |
| store @        |
| 0x0800F000 |
|                      |
|                      |
|                      |
|                      |
-------------------

[Andrew Neil]

---

@Lucifer37 wrote:

This EEPROM Emulation seems different concept

---

I'm just using it as a known-working example of how to write data to Flash, and read that data back from Flash.

Those basic principles will be the same whether you code it yourself from scratch, or use the software pack.

 

The issue of erasing the flash during programming is entirely separate - that's just down to the programming tools that you use.

As already noted, STM32CubeIDE will only erase as much Flash as it needs for the code being programmed - so you need to make sure that wherever you put your data is outside that region (or regions).

[Tesla DeLorean]

0x20000000 strikes me as a RAM address.

Perhaps use structures and a pointer to the structure. Hide an area of FLASH from the Linker so it doesn't touch or erase it. And then manage the space directly in the applications. 

The EEPROM Emulation could work similarly just carve out common FLASH pages both use for this data. TBH that's likely overkill.for things like keys, serial numbers and calibration data.

[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...