Hello,
i have to store 32-48 Byte persistent / not volatile and use LM3S5Y36 ( 16kB Flash).
The data muste be changeable during livetime ( config data from user).
I've read the datasheet and there is a note that the flash is
a) only eraseable in 1KB arrays and b) the 4 KB block have to be rewritten after 6 programming cycles of the flash.
That means I have to keep a 4KB- Block flash empty ( for 48 Bytes used data) and can use only the remaining 12KB flash for code!?
Is there an other way to store persistent, RW - data inside the controller ????
Tobias Droessler an other way to store persistent, RW - data inside the controller ????
You've bumped against an unpleasant fact - does seem wasteful. Perhaps simple 8 pin or SOT 5/6 pin EEProm is an easier - and more memory efficient solution...
You don't necessarily have to keep the 4K empty, but when you need to rewrite it, you'll need to copy it to RAM to be able to write it back. Of course, that's a very big burden on a part that only has 8K of RAM.
The next question is how often does the configuration data need to be changed? If config changes are very rare, and it's acceptable to reboot after making them, then you can almost certainly get by with using a very minimal amount of flash. If config changes are very frequent, then flash is probably not the correct place for them anyway.
Hi, Thanks for your ideas ..
The Configuration data is changed only a few times for setting parameters for working application. But I can't limit this to 6 times. And after setting new config data the controller must be reseted, but it not solves the problem of the unused 4KB block - or ?
So the only possibility is to keep this 4 KB empty or rewrite it every time( to keep it simple not every 6th time). Are there solutions/experiences with rewriting code flash? I don't know how complex this is.
Will saw my limb bit further... the fact that a capability is possible - often is imperfect justification for its adoption! Your objective is simple, straightforward - the MCU, "swallow everything" approach... anything but...
An SOT EEProm very much accomplishes your goal - quickly, easily and at minimal cost/size penalty.
While you "do battle" with this lingering issue - other aspects of your project are delayed, may suffer. Should your "volume" reach high numbers you may always "reconsider" - simply not "fill" the tiny SOT - and at that time - with that business justification - battle again with this complex, awkward & inefficient (but all in one) "solution!"
Big picture and proper guarding/management of vital resources - focus on the "real" issues - far more vital - imho...