cortex-m
cortex-m copied to clipboard
Provide storage section for writable flash memory
This may be getting a bit too complex to call "minimal", but to support applications that require some permanent storage there needs to be a section defined for that. This probably requires adding the flash page size into memory.x, then having a section something like
.storage BLOCK(_page_size) (NOLOAD) :
{
FILL(0xFF)
*(.storage .storage.*)
. = ALIGN(_page_size);
} > FLASH
If possible, aligning in between each .storage.* section would be wonderful to allow having separately erasable sections (although, I don't know any way to do so).
(Note, I have only used flash storage on the nrf51, I assume other cortex-m devices behave similarly, but this may not be general enough).
@Nemo157 you can try your idea without modifying the cortex-m-rt crate. You can write a standalone linker script, e.g. named storage.x, and then pass that as a -Tstorage.x argument to the linker (cf. cargo/config).
If possible, aligning in between each .storage.* section would be wonderful to allow having separately erasable sections (although, I don't know any way to do so).
I don't think you can do that using just linker scripts but if what will be placed in .storage are static variables you may be able to do something like this:
#[link_section = ".storage"]
static PAGE: Page = Page { bytes: [0xff; 512] };
#[repr(align = "1024")] // or w/e the page size is
struct Page {
bytes: [u8; 512],
}
You can write a standalone linker script
Yep, that's my current plan. Unfortunately you cannot have multiple SECTIONS defined in different linker scripts, so that requires copying the full link.x into the application.
It will be a little while till I get round to actually using something like this in my current project, once I do I'll see if I can come up with something that is usable in this crate (although, I think generally writing to flash will require accessing a vendor specific memory controller, so I don't know if there's some abstraction that could live here or not).
Unfortunately you cannot have multiple SECTIONS defined in different linker scripts, so that requires copying the full link.x into the application.
Is that right? It seems to work for me after a quick test. I got no linker error and the new linker section I created is there.
Hmm, you may be right. I'm sure I tested this earlier and had it ignore the sections specified in link.x when I added some extras, but it looks like it's working when I test it now.
Triage: This seems too specific to add to cortex-m-rt.
Flash memory is generally only writeable after performing some chip-specific steps, and some flash controllers might not support writes to the flash addresses at all (instead funneling writes through a single MMIO register, or via RAM-to-controller DMA without CPU intervention), so the use of this seems limited to only some chips.
Also, I would like to see HALs experiment with possible solutions for this before we consider adding this to cortex-m-rt.