Persistent data surviving re-programming within CubeIDE

[Toneski]

Hi All,

I'm sure this has been discussed before - and there's probably a solution out there, but for the life of me, I can't find it.

So here's the situation.

I have a large (~256K) block of graphics data, that sits within its own designated sectors at the top of the CPU flash. This data very rarely changes.

Is there any method that I can use, that will stop this data being re-programmed by CubeIDE everytime I change some software? Is there an IDE setting that will ignore reprogramming data/sectors that haven't  changed since the last reprogram?

Obviously, this would speed up development - which would be nice...

Cheers,

Toneski

[Andrew Neil · Accepted solution]

CubeIDE only erases enough of the flash to program the generated code - See: 

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

So is your "large (~256K) block of graphics data" part of the compiled ELF image?

If so, I guess the thing to do would be to separate it out...

[tjaekel]

What I think:

• if all code goes into internal memory (e.g. 2MB internal flash) - the debugger will whip out all and program all new
• with some "tricks" in your linker script you might be able to "exclude" memory regions - make those "invisible" for the debugger (and your code generation)
• with the linker script you can control how your code will be generated (mapped to memory) - you can make sure to reserve memory regions, "never" touched by the debugger (and potentially not deleted or programmed again)
• but: you need at least another method to program such "hidden" memory once

Yes:

• separate memory regions (via linker scripts)
• or: possible to set flash protection bits, to avoid that some flash sectors are modified

If your concern is "speed" (to flash), which is not really so much different.
If you want to avoid programming of specific flash sectors - configure your Linker Script accordingly ("hiding" memory regions or tell the linker script not to program, e.g. via "NOLOAD").

You will not really "save time" to flash (very marginal difference) and you would not increase the life-time of the flash memory by avoiding to flash some pages when the entire flash memory is still touched.

[Toneski]

Hi Andrew,

Thanks for your reply - yes I was thinking the same sort of thing - splitting off the block of data from the main ELF and programming it separately.

I see from your link that you have had pretty much the same conversation with others including ST employee's and have not got much further. It would be great if the programmer read the sector, compared to the ELF data and ignored re-programming that sector if nothing had changed. Especially as it can take up to ~2.5 seconds to erase a 128k sector, but somewhat less than this to read and compare.

Again - thanks for your input - I'll go and have a re-think.

Kudos...

Regards,

Toneski.