Writing to flash memory from application

Go To Last Post
22 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

It is possible to write to flash memory from application?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting point.

I will think about it.

In theory, is it possible to write to flash from application in run time?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No. Only from the boot program.

The largest known prime number: 282589933-1

It's easy to stop breaking the 10th commandment! Break the 8th instead. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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!!).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks clawson,

It sounds exactly as I thought.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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!

The largest known prime number: 282589933-1

It's easy to stop breaking the 10th commandment! Break the 8th instead. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

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.

 

 

Detail of still taken from "Obsoletely Fabulous (Futurama)"

Image is a detail of a still taken from the "Obsoletely Fabulous" episode of "Futurama" (Fox).

(signature pending)

Last Edited: Fri. Aug 30, 2019 - 05:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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 smiley ) was able to update his outdoor sign/panel remotely (by using low-power low-cost RF modules, also from China cheeky ).

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.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mckenzm wrote:
Can we not put an "overlay executive" in bootloader space to write needed routines over non-needed routines? From external memory, say.
Serial Bootloader though its context isn't this context.

mckenzm wrote:
A fixed project lifecycle, with defined stages that will not all fit in flash at the same time, reprogramming for transition?
Not many computer language interpreters for AVR; might consider MicroPython, Zerynth Python, MaixPy Python, or C# though likely not on an XMEGA128A1U.

mckenzm wrote:
We used to do this all the time on PC's with Turbo Pascal.
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)

 


AN_8390 AVR2054: SerialBootloader User Guide (IIRC, its source code is in Microchip Gallery | Home)

KLBasic for the Atmel AVR devices

Atto_Basic_V2)_Home

PyMite - Python Wiki

GitHub - dwhall/p14p: (INACTIVE) Python-on-a-Chip (p14p) : a tiny Python 2.6 vm (PyMite) for 8-bit and larger microcontrollers

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

Zerynth Supported Devices

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

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Fri. Aug 30, 2019 - 04:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

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 smiley), RT-11/xm with 4Mb of data memory, Yea!

 

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

 

 

(signature pending)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To be honest I haven't got the first idea what you are actually talking about.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No disrespect but LMGTFY --> https://en.wikipedia.org/wiki/Self-modifying_code

 

See also --> http://ww1.microchip.com/downloads/en/Appnotes/Atmel-2575-C-Functions-for-Reading-and-Writing-to-Flash-Memory_ApplicationNote_AVR106.pdf

 

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.

(signature pending)

Last Edited: Fri. Aug 30, 2019 - 11:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What would happen if the new subroutine is  longer than the original?

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

 

 

 

 

(signature pending)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mckenzm wrote:

An AAV may need to only use takeoff code once, and later need autolanding code, for instance.

Update the flight software of an AAV once it is in the air?

 

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]