Skip to main content
Explorer
January 16, 2025
Solved

Persistent data surviving re-programming within CubeIDE

  • January 16, 2025
  • 1 reply
  • 534 views

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

    This topic has been closed for replies.
    Best answer by Andrew Neil

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

    1 reply

    Super User
    January 16, 2025

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

    Visitor II
    January 17, 2025

    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.