cancel
Showing results for 
Search instead for 
Did you mean: 

Expand struct in flash without change location of next data

NCatt.1
Associate III

Hello everyone,

I currently have devices with a specific FW released on market. In this FW there is a structure saved in internal flash memory (with "const" and defined areas on linker file).

In the new version I am working on, I need to expand an array placed in the middle of this structure. The problem is that data next to this array will change location by doing this, what I would like to avoid.

Is there a way to add the new data of the array at the end of the structure ? Or any other idea ?

Thanks a lot for your help !

1 ACCEPTED SOLUTION

Accepted Solutions
Andrew Neil
Evangelist III

"Is there a way to add the new data of the array at the end of the structure ?"

You'd have to add another, separate array - and your code would have to cope with concatenating the two parts:

struct
{
   :
   :
   original_array[ORIGINAL_SIZE];
   next_item;
   :
   :
   extra_array[EXTRA_SIZE];   
}

"any other idea ?"

If you have plenty of Flash space to spare, Code which handles the new, bigger array just ignores the original_array, and takes everything from the extra_array.

struct
 {
    :
    :
    original_array[ORIGINAL_SIZE]; // No longer used
    next_item;
    :
    :
    extra_array[ORIGINAL_SIZE+ EXTRA_SIZE]; // Everything is now here
 }

View solution in original post

9 REPLIES 9
Andrew Neil
Evangelist III

"Is there a way to add the new data of the array at the end of the structure ?"

You'd have to add another, separate array - and your code would have to cope with concatenating the two parts:

struct
{
   :
   :
   original_array[ORIGINAL_SIZE];
   next_item;
   :
   :
   extra_array[EXTRA_SIZE];   
}

"any other idea ?"

If you have plenty of Flash space to spare, Code which handles the new, bigger array just ignores the original_array, and takes everything from the extra_array.

struct
 {
    :
    :
    original_array[ORIGINAL_SIZE]; // No longer used
    next_item;
    :
    :
    extra_array[ORIGINAL_SIZE+ EXTRA_SIZE]; // Everything is now here
 }

Andrew Neil
Evangelist III

hang on a minute:

@NCatt.1​  "The problem is that data next to this array will change location by doing this, what I would like to avoid."

Why is that a problem that you want to avoid?

Surely, the whole point of a struct is that you access its members by name - so it shouldn't matter where they appear within the struct?

This is what I thought I would have to do. This involves many changes in my code for managing it but no choice.

Thanks anyway for your answer !

Because I store device configuration in this structure, and at restart I use it to reset or not the device.

If there is a new variable between 2 restarts, variables after this new will be shifted in memory and data will be lost

@NCatt.1​ ​  "This involves many changes in my code"

Then this may be a good opportunity to re-factor your code so that's no longer the case?

eg, make "getters" for retrieving stuff from your struct - then the only change would be in the "getter" ...

If your question is now resolved, please mark the solution:

0693W000008y9fZQAQ.png

> If there is a new variable between 2 restarts, variables after this new will be shifted in memory and data will be lost

I don't understand, can you please elaborate more on this? Perhaps giving a simplified example? Or illustrate it with some drawing?

Are you talking about migration between old and new version of the firmware?

JW

@Community member​ "I don't understand"

Neither do I.

For the struct to change in Flash, the code running on the STM32 would have to update it - so that update should ensure that data is not lost?

0693W00000QKSkaQAH.pngIn both versions, at the begining there is a check of magicId, to know if the device's configuration needs to be updated (done by an app on PC). Value of magicId is always the same.

In the new version, if I expand the array, the location of magicId is shifted and does not have the correct value.

Hope it helps

That was a poor design choice, then!

magicId should be the very first thing in the struct - so that it will always be in the same place, irrespective of how the rest changes