flash (writable) variable

Log in or register to post comments
Go To Last Post
23 posts / 0 new
Author
Message
sf2000
sf2000's picture
Level: Hangaround
Joined: Sun. Nov 21, 2010
Posts: 140 View posts
#1
Posted by sf2000: Wed. Jan 12, 2011 - 03:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have used the CVAVR compiler, it works nice and allows to easily write to the eeprom just like a variable. Unfortunately it doesn't have a flash variable or easy way to write to the flash memory.

I'm looking for the Easiest way mainly to write to the flash, ideally like a variable (which can even be an array e.g. flashbuf[pagesize]) without having to start reviewing and understanding Atmel "Self Programming" A/N (Application Note).

By the way, if I understand the WinAVR is the best among the low cost or free tools. Does it allow it?

Thank you

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Top
gahelton
gahelton's picture
Level: Resident
Joined: Wed. Mar 19, 2003
Posts: 738 View posts
Posted by gahelton: Wed. Jan 12, 2011 - 04:30 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Before you can get a good answer to your questions, I have a few questions for you.

What type of "variables" to you plan on writing to flash ? Why can't these be written to EEPROM ? How often do these variables need to be changed, and under what circumstances ?

Top
Koshchi
Koshchi's picture
Level: 10k+ Postman
Joined: Wed. Nov 17, 2004
Posts: 15658 View posts
Location: Vancouver, BC
Posted by Koshchi: Wed. Jan 12, 2011 - 06:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It doesn't matter what tool chain you use, it is the AVR itself that does not allow it. You can not write to flash a byte at a time, you can only write a block at a time (and the program doing so must be in the bootloader section of memory). Flash also has a limited number of times that it can be written, which isn't conducive to using it for variables.

Regards,
Steve A.

The Board helps those that help themselves.

Top
sf2000
sf2000's picture
Level: Hangaround
Joined: Sun. Nov 21, 2010
Posts: 140 View posts
Posted by sf2000: Wed. Jan 12, 2011 - 08:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here are answers to your questions:

- Yes, the flash endurance is min 10K, no issue as I'll use it only when I'm sure that I want to write.

- The flash variable can be e.g. an array buffer with the pagesize length of the respective chip.

If I didn't answer on any question let me know.

Thank you

Top
sf2000
sf2000's picture
Level: Hangaround
Joined: Sun. Nov 21, 2010
Posts: 140 View posts
Posted by sf2000: Wed. Jan 12, 2011 - 08:01 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Why can't these be written to EEPROM ?" - because I need far more than 4KB which is the largest eeprom that the Xmega and Mega offer.

Top
lfmorrison
lfmorrison's picture
Level: Raving Lunatic
Joined: Wed. Dec 8, 2004
Posts: 4647 View posts
Location: Nova Scotia, Canada
Posted by lfmorrison: Wed. Jan 12, 2011 - 01:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You most likely have no other choice but to become familiar with the Self Programming application notes. Create a function that must be called every time you want to write to your variable. Locate that function in the Bootloader section of Flash.

Alternatively, if you're using an AVR that has an Atmel-provided bootloader preloaded in Flash, that bootloader might provide a standardized API for calling its existing Flash writing functions from application space. (Eg. the USB AVRs with a preloaded DFU bootloader.) Of course, you'd have to exercise caution in working with these APIs. You'd also have to make sure you don't accidentally erase the bootloader every time you reprogram your application.

Top
MartinM57
MartinM57's picture
Level: Resident
Joined: Thu. Dec 15, 2005
Posts: 842 View posts
Location: Bristol, UK
Posted by MartinM57: Wed. Jan 12, 2011 - 01:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

...or store in external EEPROM or FRAM (my preferred option and pretty simple using the spi library in CVAVR)

Top
kscharf
kscharf's picture
Level: Posting Freak
Joined: Wed. Aug 4, 2004
Posts: 1839 View posts
Location: Davie, FL
Posted by kscharf: Wed. Jan 12, 2011 - 02:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It almost sounds like you need an off chip file system on a flash memory chip. If you need THAT much working data space you should be using an avr chip that supports an external memory interface (atmega64, '128, '1281, '1280, '640, '2560, '2561, or one of the xmega "A1" devices).

Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 40545 View posts
Location: Wisconsin USA
Posted by theusch: Wed. Jan 12, 2011 - 02:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

It almost sounds like you need ...

I guess the right question wasn't asked above.

Quote:

I need far more than 4KB

How much more? 40KB? 400KB? 4MB? 4GB?

How often is it written? How fast do the writes need to be?

At the lower end of that size range, consider a serial memory of some sort: FRAM, EEPROM, flash.

In the middle range, a bank of flash chips may be useful.

At the larger end, I'd do SD card.

Now, if say 40KB of "spare" flash is available in the AVR, then you save a chip and the interface, etc., by writing to the AVR flash. And going to a bigger model with more spare flash space usually costs less than $1.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top
kscharf
kscharf's picture
Level: Posting Freak
Joined: Wed. Aug 4, 2004
Posts: 1839 View posts
Location: Davie, FL
Posted by kscharf: Wed. Jan 12, 2011 - 03:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

Now, if say 40KB of "spare" flash is available in the AVR, then you save a chip and the interface, etc., by writing to the AVR flash. And going to a bigger model with more spare flash space usually costs less than $1.
Declaring a program space "variable" and updating it will require some mental gymnasitics to convince the compiler to do what you want to get the pointers right. Plus locating the code to do the write into the bootstrap space might make it seem easy to whistle Dixie while drinking water.

Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 40545 View posts
Location: Wisconsin USA
Posted by theusch: Wed. Jan 12, 2011 - 03:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Declaring a program space "variable" and updating it will require some mental gymnasitics to convince the compiler to do what you want to get the pointers right. Plus locating the code to do the write into the bootstrap space might make it seem easy to whistle Dixie while drinking water.

Wasn't there a "sound recorder" app for AVRs that did this? There is the AVR335 app note using external dataflash, but I seem to recall a "native flash" implementation.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top
sf2000
sf2000's picture
Level: Hangaround
Joined: Sun. Nov 21, 2010
Posts: 140 View posts
Posted by sf2000: Wed. Jan 12, 2011 - 03:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks everyone.

I personally don't see any issue that a compiler will provide e.g. flashbuffer[pagesize] which could be written at any time, but the actual write will be a calling to some ready procedure e.g. writeflash.

As for the question, I just need say 10KB or so. And regarding the endurance, if every Flash page can be written 10K times, then it's well more than I need.

Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 40545 View posts
Location: Wisconsin USA
Posted by theusch: Wed. Jan 12, 2011 - 03:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

As for the question, I just need say 10KB or so.

OK, so the answer to one question was finally pulled out of you. Now, what about:
Quote:

How fast do the writes need to be?

That becomes important in a "streaming" app, such as logic analyzer or event recorder with high-speed sampling. Bootloader gurus can comment more, but even in the internal AVR flash there will be page erase time and page write time.

Yeah, for 10KB the internal flash is interesting. For simplest dev especially if the last penny isn't important I'd go with an FRAM chip.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top
kscharf
kscharf's picture
Level: Posting Freak
Joined: Wed. Aug 4, 2004
Posts: 1839 View posts
Location: Davie, FL
Posted by kscharf: Wed. Jan 12, 2011 - 04:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Don't you have to tie up a flash page worth of ram to hold the data being written? That's not an issue inside of a bootloader (usually) but in a full blown app it might be.
(what is a flash page size 256 bytes?)

Top
sf2000
sf2000's picture
Level: Hangaround
Joined: Sun. Nov 21, 2010
Posts: 140 View posts
Posted by sf2000: Wed. Jan 12, 2011 - 04:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lee - faster is better, but not special significance to speed.

kscharf - sorry for my English, not sure what exactly you meant, if using internal and/or external SRAM to store data then it requires a permanent large battery, so I wouldn't be keen to do it.

Thank you

Top
kscharf
kscharf's picture
Level: Posting Freak
Joined: Wed. Aug 4, 2004
Posts: 1839 View posts
Location: Davie, FL
Posted by kscharf: Wed. Jan 12, 2011 - 04:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sf2000 wrote:
Lee - faster is better, but not special significance to speed.
kscharf - sorry for my English, not sure what exactly you meant, if using internal and/or external SRAM to store data then it requires a permanent large battery, so I wouldn't be keen to do it.
Thank you

No, I meant to be able to write to flash you need to buffer the data in sram a page at a time.

Top
sf2000
sf2000's picture
Level: Hangaround
Joined: Sun. Nov 21, 2010
Posts: 140 View posts
Posted by sf2000: Wed. Jan 12, 2011 - 05:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"For simplest dev especially if the last penny isn't important I'd go with an FRAM chip." - it's an option, however like any other thing it has its own disadvanatges:

- More 'penny'
- Larger PCB size
- Learning communication protocol with this part

Top
gahelton
gahelton's picture
Level: Resident
Joined: Wed. Mar 19, 2003
Posts: 738 View posts
Posted by gahelton: Thu. Jan 13, 2011 - 01:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You might also want to consider an external serial flash device such as:

http://www.numonyx.com/Documents/Datasheets/M25P05A.PDF

Advantages are, easy serial interface to AVR, and more storage. Also, there is a considerable advantage to the external memory approach where you don't have to worry about "blowing you're flash brains out".

If you just have to store your "variables" in flash, then follow the flash programming examples in the datasheet, and write your own. Don't depend on the compiler to do this for you. You could spend a lot of time trying to coax the comipler into doing this, and it still might not work the way you expect.

Top
lfmorrison
lfmorrison's picture
Level: Raving Lunatic
Joined: Wed. Dec 8, 2004
Posts: 4647 View posts
Location: Nova Scotia, Canada
Posted by lfmorrison: Thu. Jan 13, 2011 - 01:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kscharf wrote:
sf2000 wrote:
Lee - faster is better, but not special significance to speed.
kscharf - sorry for my English, not sure what exactly you meant, if using internal and/or external SRAM to store data then it requires a permanent large battery, so I wouldn't be keen to do it.
Thank you

No, I meant to be able to write to flash you need to buffer the data in sram a page at a time.

Not necessarily. The AVR's Flash memory controller already has a "hidden" page-sized RAM buffer, ready to roll. You flash modifying routine can work like this:

1) Identify the portion of the Flash page that needs to stay the same.
2) Identify the portion of the Flash page that needs to change.
3) Fill the leading part of the "hidden" Page Buffer by copying the existing leading Flash contents that need to stay the same, if any.
4) Fill the middle section of the Page Buffer with the data that needs to change, copying from whatever data source is being used to generate the changed data.
5) Fill the trailing part of the Page Buffer by copying the existing trailing Flash contents that need to stay the same, if any.
6) Issue the Page Erase command.
7) Issue the Page Program command.
8) Repeat for any other pages that need to change.

Top
sf2000
sf2000's picture
Level: Hangaround
Joined: Sun. Nov 21, 2010
Posts: 140 View posts
Posted by sf2000: Thu. Jan 13, 2011 - 12:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank all.

I never said that there's any issue of insufficient RAM. Also didn't understand the point with sections 1-5 and the leading/middle/trailing sections of the page i.e. the data to be written into the page are determined by the user.

Top
lfmorrison
lfmorrison's picture
Level: Raving Lunatic
Joined: Wed. Dec 8, 2004
Posts: 4647 View posts
Location: Nova Scotia, Canada
Posted by lfmorrison: Thu. Jan 13, 2011 - 12:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Also didn't understand the point with sections 1-5 and the leading/middle/trailing sections of the page i.e. the data to be written into the page are determined by the user.

That was intended to anticipate the possibility that you sometimes might want not always want to change the entire page all at once. Maybe sometimes you only change a couple of bytes while leaving the rest intact.

Basically, I figured, if you were going to proceed with this idea, it would be most useful to create a sort of generic memcpy_F(destination, source, size) high-level function, which would accept a destination address pointing at "any byte" in Flash*, regardless of whether or not it begins exactly on a page boundary, and which would accept a size of any arbitrary value, regardless of whether or not it adds up to a full integer multiple of page sizes.

In order for that to work, you'd need to take special care to preserve the existing contents of any Flash outside the range specified by destination and size, within in the same page as the data you want to modify. Otherwise, it would all get erased.

_________________________

* "Any byte" in Flash, in this case, would most likely be qualified to ensure that it would be impossible to accidentally include areas of Flash which would be unsafe to modify, such as areas containing executable code.

Top
sf2000
sf2000's picture
Level: Hangaround
Joined: Sun. Nov 21, 2010
Posts: 140 View posts
Posted by sf2000: Thu. Jan 13, 2011 - 03:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks however I'm not going to get into such level of complications (it's exactly what I'm trying to get rid from...), endurance of 10K writes is fine for me.

It seems that the free C compiler and even the cost ones don't offer such a simple issue of flash var, most pity.

Top
lfmorrison
lfmorrison's picture
Level: Raving Lunatic
Joined: Wed. Dec 8, 2004
Posts: 4647 View posts
Location: Nova Scotia, Canada
Posted by lfmorrison: Thu. Jan 13, 2011 - 08:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sf2000 wrote:
Thanks however I'm not going to get into such level of complications (it's exactly what I'm trying to get rid from...), endurance of 10K writes is fine for me.

I'm sorry if I didn't explain myself well enough: I wasn't in any way referring to the the 10K limit or anything like that.

(The entire page gets erased every time anything on the page changes, so my method wouldn't have done anything to address prolonging Flash lifetime.)

My post was all about creating a system whereby Flash vars could be handled relatively conveniently, using an analog to a well-known convention for memory transfers, namely in this case, memcpy().

There'd be some extra effort in the beginning to get the interface working. But after it was up and running, it would effectively fill in the gaps left behind by the compiler, by providing you with a very simple, flexible primitive function you could use for handling "Flash vars" of any arbitrary size, with relatively few restrictions on their locations.

Quote:
It seems that the free C compiler and even the cost ones don't offer such a simple issue of flash var, most pity.

Any solution a compiler adopted, would impose severe limitations on the application developers' flexibility to structure their own bootloaders according to their own requirements.

(Remember: It is impossible to consider the way in which modifiable flash vars could be handled, without also taking into account the system by which the bootloader (if present) will operate.)

Top