Go Down

Topic: Get program size (flash used) RUNTIME - possible? (Read 1 time) previous topic - next topic

bperrybap



Instead of thinking all the things you shouldn't do and 'just saying no', what about the things reasonable that may deserve a 'yes'? An open approach instead of closed?


Yes, but writing to flash (program memory) at runtime isn't really a desirable thing to do. Sure, we can be open about it. But if you do it 10 times a day, and the flash can be written to 10,000 times, your app will fail after 3 years.

It might be. There are some legitimate uses to overwrite the running code in flash.

With respect to the number of writes, it depends on where the write(s) is done.
The 10,000 times is per page. If you are updating the flash with a minimal
change it will potentially only impact a single page. Since there are many pages in flash the actual number
of writes could be much higher than 10,000 times if the writes are being done on different pages.

Quote

Plus, it would be easy, if you enable writing to flash, to corrupt the running program. Do you want that?

I could think of reason to want to do this: Debugging.
Suppose you want to run gdb for source level debugging and insert a break point.
The way to do this is to "corrupt" the running code with a new bit of code where you
want the breakpoint to be.
The Atmel ICE products do this by "corrupting" (overwriting) the existing code
with a BREAK instruction. They read the appropriate flash page
and re-write the page with the BREAK instruction inserted in the correct place.

It is possible to do the same (overwrite code with a special instruction)
without an ICE in the code itself to allow gdb to talk to through the serial port on the AVR by
using a similar approach. You can't use the BREAK instruction because that is reserved by ATMEL when
the OCDEN fuse enables 1 wire debugging (debugwire).
You can do it through a cleaver use of an instruction to trigger a hardware interrupt
(INT0 is best to gain full control) to cause a trap into an ISR.
From there the code can take over and talk out the serial port and eventually
back to gdb to transfer all the relevant information using gdbmon messages.
Yes it is a bit tricky and it does require the ability to overwrite flash pages
but it allows using the AVR serial port for source level debugging.
It also requires a custom version of gdb to modify the "breakpoint" instruction
to the needed instruction opcode to trigger the interrupt because currently the opcode
for the "breakpoint" instruction is hard coded into gdb as BREAK and BREAK
can't be used since it only works for debugwire.

--- bill

GoForSmoke

Or perhaps I might make a generic combo PDA and electronic key that a user would enter personal data that won't change any time soon. It might have certain code and data but also have room for more without overwriting anything but empty space. I could do that now if my users were expected to load the device from a PC/ISP but maybe I'd rather not have them do that for whatever reason.
It's hard to say before the app is thought of except yo, I'd like the freedom to do that.
I find it harder to express logic in English than in Code.
Sometimes an example says more than many times as many words.

bperrybap

A real-world application that I've tossed around is a serial glcd backpack.
glcd fonts and bitmaps can be quite large and as such are stored in flash.
In a backpack product, it might be useful to provide a way to
update/modify a font or a bitmap splash image.
For that usage case it might be nice to be able to reserve areas in flash
for font/bitmap storage that can be updated and overwritten using the serial communication
interface.


So in this usage case it really isn't updating "code" but rather an area of the flash that is
reserved for data that can be modified because eeprom is not large enough.
And if that area starts right after the end of the real code vs a hard coded location,
knowing where the code ends becomes quite useful.
Even if the data starts high and starts to move down towards the code, knowing how much
room is available is needed to determine how space is available for data storage.

--- bill

GoForSmoke

You could PROGMEM the initial data and use a pre-set pointer to tell where it is.

I find it harder to express logic in English than in Code.
Sometimes an example says more than many times as many words.

Go Up