Is it possible to free the amount of free flash memory?
I have a program that uses PROGMEM heavily to move data out of SRAM and into FLASH. Its working as planned, however, I'm suspecting that the program is using up all the FLASH, and crashing.
I'm already using code to make sure I don't run out of RAM, but cannot find code to check the FLASH memory.
Suggestions?
powellbob424:
I'm suspecting that the program is using up all the FLASH, and crashing.
Which is impossible. You will know when you upload if enough Flash is available. You will know because the upload will fail.
Also the system tells you how much flash its used when compiled: "Binary sketch size nnnnn bytes out of a mmmmm byte maximum"....
I'm sorry, I wasn't clear. I'm adding and holding data as needed in FLASH thanks to PROGMEM. If the variable was static, then its size would appear in the compiled sketch when its uploaded.
My data is not. I'm manipulating and changing it as if it were in RAM. So my variables are outside of the sketch, but still part of FLASH memory. Hence the question. How do I find out how much FLASH memory is left?
Thanks
powellbob424:
I'm sorry, I wasn't clear.
Your second post is no better.
I'm adding and holding data as needed in FLASH thanks to PROGMEM. If the variable was static, then its size would appear in the compiled sketch when its uploaded.
The size of all initialized data appears in the compiled sketch when it is uploaded. It makes no difference if the data is tagged PROGMEM or not.
I'm manipulating and changing it as if it were in RAM.
If you are manipulating data as if it were in SRAM then the data is in SRAM.
How do I find out how much FLASH memory is left?
powellbob424:
I'm sorry, I wasn't clear.Your second post is no better.
Perhaps the 3rd time will be a charm.
I'm adding and holding data as needed in FLASH thanks to PROGMEM. If the variable was static, then its size would appear in the compiled sketch when its uploaded.
The size of all initialized data appears in the compiled sketch when it is uploaded. It makes no difference if the data is tagged PROGMEM or not.
Your right, but since my data is NOT being initialized, only pointers to the data, its not part of the compiled sketch. The data will be in FLASH memory later, OUTSIDE of the compiled sketch. Hence my problem.
I'm manipulating and changing it as if it were in RAM.
If you are manipulating data as if it were in SRAM then the data is in SRAM.
NO - Its not in SRAM, its in FLASH. That's the point PROGMEM -- to move data out of SRAM and into FLASH.
How do I find out how much FLASH memory is left?
If reply 2 answered my question, I wouldn't have asked again. Its quite possible with PROGMEM to have a perfectly sized sketch, then use up the remaining FLASH. Thats why I'm asking the question.
powellbob424:
If reply 2 answered my question
It does answer your question.
I wouldn't have asked again.
Repeating the same mistake and expecting a different result. I wonder what that indicates.
At this point you should start to suspect that you are asking the wrong question. And excluding too many details from your description. And failing to post code that illustrates the problem. And not adequately describing the problem.
I'm adding and holding data as needed in FLASH thanks to PROGMEM.
You can't "add" to PROGMEM data in flash at runtime; PROGMEM is read-only data. you use pgm_read_byte() or similar to read the data from PROGMEM variables, and there is no equivalent for writing data. (The "bootloader section" of the AVR can write to flash, but that doesn't use PROGMEM and requires manual operations considerably more complex than dereferencing pointers. And Arduino sketches are not in the bootloader section, so they can't do it anyway.)
Now, the flash memory space goes from 0 to 32k, and part of that overlaps the RAM address space (which goes from 0x100 to 2k+0x100), so if you carelessly dereference PROGMEM pointers, you'll end up reading/writing to RAM instead, which MIGHT look like it's working as long as the addresses you write doesn't overwrite data important for something else...)
The clue is the phrase "Flash ROM"...
Flash can only be written a page at a time by erasing the page and then
writing it all, and its takes a long time. This is what happens when you upload
a sketch. As mentioned only the bootloader can do this.
EEPROM can be written a byte at a time, but is still slow to write and there
isn't very much of it.
powellbob424:
The data will be in FLASH memory later, OUTSIDE of the compiled sketch.
Which flash memory are you referring to here? If you're referring to the internal flash memory that holds the bootloader and sketch, then what method are you proposing to use to write to it? The sketch can't write to it, and the bootloader will only write to it when uploading a new sketch, which would consist of the compiled image.
What you're trying to do suggests either you're trying to do something extremely clever with flash (and if you know how to do that then working out the free flash space would be the least of your problems) or you have misunderstood what flash memory is and what you think you're doing won't work.
If you think what you're trying to do is sensible then I suggest you explain in more detail how you propose to use flash storage. This will reassure us that you do understand how flash works and that what you're trying to do is sensible, and give us the background to offer sensible advice about how to do it.
I'd like to think I'm doing something clever, but time will tell. I already have routines to check and verify how much space is being used in SRAM and EEPROM. Those were relatively easy since libraries already exist. Now, I'd like something for FLASH. What I do NOT want to do is overwrite the bootloader or sketch. So far, I have not overwritten the bootloader, but suspect I may have already overwritten sketches in the past. Hence, the crashing.
So the question is whether its possible to check for unused space in FLASH memory?
The compiler/linker will tell you.
The linker produces a symbol "_etext" just beyond the last flash address used. So this should be the first free flash location when your sketch starts. As you write flash, you'd have to keep track of how much you've written on your own. (though I still suspect that things are not going to work the way you expect. The AVR is NOT one of those architectures where it is "easy" to use the flash program memory as non-volatile storage. You might look at "amforth" as an example of a program that does rewrite flash on the fly...)
extern const short PROGMEM _etext;
void loop()
{
delay(2000);
fp("\nCompiled for " __CPUNAME "\n");
fp("Etext = 0x");
Serial.println((unsigned long)&_etext, HEX);
Produces:
Compiled for ATmega328P
Etext = 0x1DC2
I'd like to think I'm doing something clever, but time will tell.
it is time ...
You are not.
Your code can not write to flash memory, no matter how clever you think you are. The hardware does not allow it to happen.
powellbob424:
I'd like to think I'm doing something clever
You have still not given enough information to tell whether you're being cunning, or barking completely up the wrong tree. The more time passes without you explaining what you have in mind, the more I'm inclined to suspect the latter.
powellbob424:
So the question is whether its possible to check for unused space in FLASH memory?
When, where and why do you want to do this 'check'?
What I have in mind is simple, can I test the flash memory from within a sketch? The answer seems to be no. I'm already writing to the flash outside of the sketch, so saying that it can't be done is useful. And if I really want to, I can test the flash with an ISP and see what's left. In fact, I had to reload the bootloader yesterday on one chip. So it can be done from outside a sketch.
The code I have now is constantly checking what is available in RAM, pushing to FLASH or EEPROM, and as a last resort the SD card. The slow I/O of the SD card is causing other issues, but eventually we could work around those issues.
So can it be done? Its a high level question that if the answer is yes, I only need a point in the right direction. If the answer is no, then fine. Eventually, I'll figure out a way.
You can certainly READ the flash memory from within a sketch. So you could theoretically start from the known end of flash and scan pages until you find one that isn't full of 0xFF (pages full of 0xFF at the end of flash are presumably "unused.")
I still don't see how you expect to "push to flash", though.
You could look at serial flash/eeprom, which is physically easy to connect to the AVR (slightly easier than an SD card), and MUCH easier to write to than an SD card (no filesystem; just a straight memory array.) Not anywhere near as large as an SD card, but you should be able to get about 1MB for reasonable cost (actually, ridiculously cheap...): http://www.digikey.com/product-detail/en/S25FL208K0RMFI041/1274-1051-ND/3862736 is one example
The problem with writing to flash from a running program is that you either have to
a) make the whole of flash memory the boot sector and suffer the inevitable consequence of overwriting your program if when you screw-up, or
b) rewrite (and considerably expand) the existing bootloader to act as bootloader and flash writing agent for the running program.
None of this is impossible or particularly difficult, but given the limited number of erase/write cycles on flash, the other suggestions are more than worthwhile exploring.
You can only write to flash if the code is running in the the last segment of the memory. This is where the boot loader lives, so in theory you could rewrite the boot loader to allow you to write to flash.
However the boot loade takes up all that memory space so you will need to program the arduino another way after you replace the boot loader . It then ceases to be an arduino.
You can only write to flash if the code is running in the the last segment of the memory
IIRC, You can also lift the restrictions on using LPM and SPM in the application area by blowing the SELFPRGEN fuse, or by using the lock protection bits (there's a subtle distinction between the methods, but I forget what it is right now), but I agree, by that point, you're not in Kansas anymore.
Making the mechanism possible is very simple, but making it safe and reliable is tricky.