I have a really insane idea where I’d like to replace some flash data in my code. How difficult would it be to track down some specific data in a currently flashed application and replace it?
From what little I know, you’d have to erase an entire page of flash at a time,
so even if it were possible it would be tricky to pull off.
Not to mention the page has to not have any important machine code instructions stored on it.
You could possibly forcively reserve a page of memory by abusing alignment and arrays,
and maybe (if it exists and functions correctly) some kind of compiler specific attribute for specifying the address to store the variable at.
So probably a lot harder than I suspected then… oh well.
Did you have a particular purpose in mind or were you just wondering if it’s possible?
I see @FManga typing, I wonder if he’s going to mention the “Pokitto DLL” idea from all that time ago…
I’ve been planning on doing the same if I ever have the chance to actually write a game for the Pokitto.
@Pharap is right in that it needs to be page-aligned and the page you’re writing can’t contain code that is executing during the write.
It can actually be pretty simple to do and doesn’t require compiler extensions or linker scripts:
On the Pokitto, flash starts at address zero and goes up to 0x40000.
Your program starts at 0. Say it’s a 100kb bin. You know that anything after address 0x20000 (give it some margin) is free to use (erm, don’t overwrite the loader 
).
The PokittoLib already has the code to write an array from memory to flash.
Just read your data to RAM and copy it to an address you know you can use.
2 Likes
Ah yes, I forgot that the loader can do that.
I now know what you meant by ‘DLLs’ back then.
I can think of at least three other good ways to use it though.
(Probably more given time.)
That was different. The idea was to put code in RAM, not flash. Later on it became the Extensible Loader.
ARM Cortex M0+ can execute RAM?
I would have thought that would be disabled for security reasons.
Yes, it can, unlike AVR chips. 
AFAIK, the only ARMs that don’t allow execution from RAM are those that have an MMU that can be configured that way.
2 Likes
My idea was mostly fro the novelty, but I want to read randomly from a file at a reasonable speed. I was thinking maybe copy the file to flash and access it as a byte array.
You could do that with RAM already.
Though if memory is an issue then this is probably a good solution.
I’m presuming you’re planning to use it for music?
Nah, for a background image.
But that’s sound idea sounds interesting.
1 Like
Not half as interesting as using it to load compiled bytecode for a scripting language. :P
Or loading level data for a game into flash rather than RAM,
leaving the RAM free for other things.
Or computing lookup tables in RAM at start up and then moving them into flash to free up the RAM for other things.
(Though that’s probably less useful because computing the lookup table could be done before compiling.)
1 Like
Sounds quick and simple enough: Read the entire file into the framebuffer then copy that to flash.
In theory yes.
This is a very good idea 
1 Like