Hi,
It is possible to write to flash memory from application?
arkadi
Writing to flash memory from application
Author
Message
rev From a bootloader then yes.
In run time then no.
i guess the question is why you want to write to flash ?
If it for non volatile stuff then use eeprom.
Paul
arkadi
Hey Paul,
I want to write "big" data (some KB) and do it a lot of times, so I think it is better to use FLASH memory.
clawson 
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 104728 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
arkadi wrote:
and do it a lot of times, so I think it is better to use FLASH memory.
You know about the paged nature of the flash and the fact that any particular page cannot be erased more than 10,000 times during the life of the app don't you? Does the code flash STILL look like a good choice?
Most people would add an external memory device - often an SD/MMC card.
For small amounts of data the EEPROM is a better choice than code flash (bytes not pages and 100,000 cycle not 10,000 cycle life)
arkadi
Interesting point.
I will think about it.
In theory, is it possible to write to flash from application in run time?
Torby 
Level: 10k+ Postman
Joined: Tue. Nov 11, 2003
Posts: 10441 View posts
Location: Bartlesville Oklahoma USA
No. Only from the boot program.
If you don't know my whole story, keep your mouth shut.
If you know my whole story, you're an accomplice. Keep your mouth shut. 
clawson
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 104728 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
arkadi wrote:
, is it possible to write to flash from application in run time?
That is exactly what a bootloader does.
In fact, although you won't be writing a true bootloader as such you will employ a lot of the same mechanisms.
The way flash is rewritten at run time is using the AVR's SPM (Self Program Memory) opcode. However this cannot be run from just anywhere in the flash (it would involve "pulling the rug out from under your feet"!!) so the AVR (apart from Tiny) requires that it be run in the "bootloader section" (BLS).
So you add some functions to your existing code but arrange for them to be "placed high up". When you have data to be written it invokes these "high" functions that are located at or above the BLS boundary. It runs and invokes SPM to reprogram memory (and while it is doing it the code in the app section "disappears"). When the process is finished the app code is made visible again and the high functions RET back to what is visible again (as long as you didn't accidentally write over it!!).
arkadi
mojo-chan
If you need to write a lot of data then flash memory (Dataflash is easy) or FRAM might be a better choice. FRAM in particular is very easy to use and has infinite re-write cycles.
Torby
Level: 10k+ Postman
Joined: Tue. Nov 11, 2003
Posts: 10441 View posts
Location: Bartlesville Oklahoma USA
mojo-chan wrote:
If you need to write a lot of data then flash memory (Dataflash is easy) or FRAM might be a better choice. FRAM in particular is very easy to use and has infinite re-write cycles.
Those are cool chips. Thanks for the tip!
If you don't know my whole story, keep your mouth shut.
If you know my whole story, you're an accomplice. Keep your mouth shut.
mckenzm
Can we not put an "overlay executive" in bootloader space to write needed routines over non-needed routines? From external memory, say.
An AAV may need to only use takeoff code once, and later need autolanding code, for instance.
A fixed project lifecycle, with defined stages that will not all fit in flash at the same time, reprogramming for transition?
We used to do this all the time on PC's with Turbo Pascal.
Image is a detail of a still taken from the "Obsoletely Fabulous" episode of "Futurama" (Fox).
Last Edited: Fri. Aug 30, 2019 - 05:59 AM
clawson
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 104728 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Bear in mind the 10,000 cycle life of the AVR. So if you only plan to do this every few days or something then that should be fine. But if it's every time the AVR is powered on then it could start to eat into the life.
KerimF 
In the past (before 2011), when I was able getting SST89E58RD (C51 family) from China, I used saving the user text data in its flash memory.
Obviously, I had to write a suitable bootloader which read (via I2C routine) an external SEEP (embedded in a smartcard for example) and save its contents in some parts of the application section.
By doing this, even the entire application section (code + data) could be updated.
Actually, the user (and I 
) was able to update his outdoor sign/panel remotely (by using low-power low-cost RF modules, also from China 
).
But, about 8 years ago, I had to stop the project and start a new one; power DC to AC inverter/charger for houses (using ATmega8).
I guess, the AVR family is somehow equivalent to the SST family in this respect.
gchapman
Level: 10k+ Postman
Joined: Tue. Jan 9, 2007
Posts: 16409 View posts
Location: Clay County, Texas, u.S.A.
mckenzm wrote:
Serial Bootloader though its context isn't this context.
Can we not put an "overlay executive" in bootloader space to write needed routines over non-needed routines? From external memory, say.
mckenzm wrote:
Not many computer language interpreters for AVR; might consider MicroPython, Zerynth Python, MaixPy Python, or C# though likely not on an XMEGA128A1U.
A fixed project lifecycle, with defined stages that will not all fit in flash at the same time, reprogramming for transition?
mckenzm wrote:
A team I was on did similar on a DEC PDP-11/34 with FORTRAN on RT-11 (16-bit address space, paged object code from "large" spinning platters of iron oxide on aluminum) (real-time control of Test & Measurement with an operator interface)
We used to do this all the time on PC's with Turbo Pascal.
AN_8390 AVR2054: SerialBootloader User Guide (IIRC, its source code is in Microchip Gallery | Home)
KLBasic for the Atmel AVR devices
Python for the 8bit AVR mocrocontroller · Issue #3699 · micropython/micropython · GitHub
https://github.com/micropython/micropython/tree/master/ports/pic16bit (dsPIC33FJ256GP506)
PIC24 EPMP can address 16MB SRAM, MRAM, or F-RAM.
dsPIC33C was announced northern summer'18 but doesn't have EPMP; the single-core dsPIC33CK has PMP, IIRC 128KB, so might still be considered.
PIC24FJ1024GA610 - 16-Bit - Microcontrollers and Digital Signal Controllers
via MAPS - MCUs & MPUs page (in the Parallel Port pull-down menu select EPMP)
MicroPython - Python for microcontrollers
MaixPy (Python on one instance of RISC-V)
nanoframework – Making it easy to write code for embedded systems. (C#)
https://en.wikipedia.org/wiki/PDP-11_architecture#Memory_expansion
edit :
Ch is a C/C++ interpreter though on MPU (starts at the level of SAMA5, Linux or QNX)
Embedded and embedding Ch | System Requirements
Last Edited: Fri. Aug 30, 2019 - 04:08 PM
ki0bk
gchapman wrote:
A team I was on did similar on a DEC PDP-11/34 with FORTRAN on RT-11 (16-bit address space, paged object code from "large" spinning platters of iron oxide on aluminum) (real-time control of Test & Measurement with an operator interface)
That brings back memories(pun intended ), RT-11/xm with 4Mb of data memory, Yea!
mckenzm
Bear in mind the 10,000 cycle life of the AVR.
I was thinking more of an application that was effectively single use, so this would not necessarily be repeated all that frequently.
.. and not bootloading per se, but "self" programming.
We would never do this, we would just ugrade. But for something already launched it might have been an option. Like deleting log files.
I am aware of being able to "poke" parameter values into a subroutine, this would also be destructive, but periodic displacement of the subroutine as a kind of primitive wear levellling technique springs to mind. Minding that we may writing a page, so maybe duplicate the routine written to and also update a vector every x000 updates? Easier to have the parameter in a register, no?
I have an IP powerboard (IP9258) that destructively tests a location in eeprom every boot, it is not rebooted that often.
My 14yo daughter for a project used command line Arduino from a Rasberry Pi Zero W to reprogram a nano. (I know, rather than just using the RPi). Scripted download from GitHub.
There is a parking meter I use in Tuggeranong (!) that has 7 AVR mcus surrounding embedded windows (!). One is just for the coin tray. Each mcu has versioned firmware. It will still theoretically last 20+ years if any are flashed once a day.
clawson
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 104728 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
mckenzm
No disrespect but LMGTFY --> https://en.wikipedia.org/wiki/Self-modifying_code
My question is:
Suitably located and padded (in a similar manner to incremental linking), could we not "swap out" entire subroutines that have served a purpose, for others, now required?
In other words overlay new code over old, with running application code.
Last Edited: Fri. Aug 30, 2019 - 11:38 PM
ka7ehk
What would happen if the new subroutine is longer than the original?
Jim
mckenzm
This is why you would leave a gap. Hence my reference to incremental linking, which left gaps for changes in object modules in a statically linked product.
Although it follows that if you contracted enough of these gaps you would probably have room for conditionally executed code anyway.
I imagine we would only resort to this if there was a hardware constraint, such as re-engineering an existing device ala OpenWRT. plus our code would be displacing any real bootloader.
clawson
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 104728 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
I have been programming micros since the late 70's so I'm well aware of self modifying code but I still fail to understand how this helps in the AVR Harvard environment. (And it was an atrocious idea back in the 70's anyway)
joeymorin
mckenzm wrote:
Update the flight software of an AAV once it is in the air?
An AAV may need to only use takeoff code once, and later need autolanding code, for instance.
Launch an AAV without the means to land it already onboard?
Remind me never to hire you for any mission critical work.
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
 |
mosa_zahany
yes it is posible ;) by som hack -- 1.write an api in boot loader for writing a page . call that from program arya . for api adress you can search boot arya .contact mosa_zahany@gmail.com for source
ccrause
mckenzm wrote:
... but periodic displacement of the subroutine as a kind of primitive wear levellling technique springs to mind.
Wear leveling is something I have been pondering, since my hobby projects typically evolve incrementally, resulting in the start of flash being pummeled every upload cycle, while the upper say 60-80% is rarely touched. My idea of a flash wear tool would be an external tool keeping track of used pages and chopping up the code at call entry points and distribute the code pages either randomly (subject to usage constraints such as interrupt vector and bootloader locations) or using a schedule per controller (difficult if there isn't a UID associated with each controller). The reset vector will have to be updated just about every time, so no rest for page 0...
I realize this is off-topic and impractical...