Read-While-Write Flash memory

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Linked to my previous post, here I'd like to discuss another topic  
related to persistent variables.

Some years ago I used microcontrollers with internal EEPROM memory or I  
used external serial I2C EEPROM to save persistent variables.  It seems  
to me the scenario has recently changed.

With new Cortex-M microcontrollers, internal EEPROM is typically absent,  
but the manufacturer explains in every details (with source code too)  
how to use internal Flash for data storage (EEPROM emulation).
This saves some cost and PCB area (and I think it saves some cost to the  
manufacturer too... maybe the process to integrate a real EEPROM is high).

Atmel SAM D20 Cortex-M0+ has an internal Flash memory that can be  
splitted in two sections: one for application and one for EEPROM  
emulation.  Application Note AT03265 explains how to use it [1].

I think there's an obscure issue when using internal Flash memory for  
data storage.  It is the page (Atmel names it row) erase time that could  
be some milliseconds (6ms for SAM D20).
If the application needs 4 rows (4*256 byte=1kB) to save all persistent  
data, the sabing process will take about 24ms.

I don't know what do you think about it, but I try to split the actions  
in pieces that doesn't block, so the firmware can be more responsive to  
asyncronous events (pushing of buttons, commands from UARTs, ...)
Blocking the firmware for 24ms seems to me a very *long* period.

I don't think there is a solution.  You can't decompose the saving  
process in a state-machine, because you can't continue executing the  
application from Flash memory during erasing process of some rows in the  
*same* Flash memory. Right? You are forced to wait for the erase (and  
write) process end.

Now I'm studying the datasheet of new Atmel SAM C21 Cortex-M0+  
microcontroller.  It works with a 5V power supply and this is not common  
for this type of micros. Moreover I noticed the presence of an  
additional section of internal Flash memory that is named RWWEE  
(Read-While-Write EEPROM).

     "It is not possible to read the RWWEE area while the NVM main array
      is being written or erased, whereas the RWWEE area can be written
      or erased while the main array is being read."

In this case, is it possible to continue executing of "normal"  
application that resides in the main memory during the saving process  
(erasing and writing of rows in the RWEE memory)?
If it is possible, I could decompose the saving process in a  
state-machine in such a way there isn't any blocking point.  I can stay  
in the "ERASING" state until the erasing operation finished.  Of course,  
the state-machine stay in "ERASING" state, but the main execution  
process isn't blocked.

Is this exactly the goal to have a RWWEE additional Flash memory on this  
microcontrollers?


[1]  
http://www.atmel.com/Images/Atmel-42125-SAM-EEPROM-Emulator-Service-EEPROM_ApplicationNote_AT03265.pdf

Re: Read-While-Write Flash memory
Quoted text here. Click to load it

Yes.

OTOH, I can't purchase C21 micros from anywhere. Can you?

Re: Read-While-Write Flash memory
Il 15/08/2016 05:51, snipped-for-privacy@gmail.com ha scritto:
Quoted text here. Click to load it

Yes, you can purchase a few pieces them from Digikey, but even Arrow  
distributor (in Italy) gave me a quote, without problems for delivering.

http://www.digikey.it/product-search/it/integrated-circuits-ics/embedded-microcontrollers/2556109?k=&pkeyword=&FV=ffeccb1e%2Cfff40027%2Cfff800cd&mnonly=0&newproducts=0&ColumnSort=0&page=1&stock=1&quantity=0&ptm=0&fid=0&pageSize25%



Re: Read-While-Write Flash memory
luni, 15 august 2016, 16:50:45 UTC+3, pozz a scris:
Quoted text here. Click to load it

Thank you,

I didn't bother to check Digikey, I checked Mouser and Farnell with 0 results.
OTOH, the prices are quite high, at least compared to Kinetis E family
(also 5V). However, the prices for the C21 are for the big 256K parts.
It would be interesting to find prices for the 32K and 64K chips.

Re: Read-While-Write Flash memory
On 14/08/16 23:37, pozz wrote:
Quoted text here. Click to load it


you want.  They are very small and cheap.  Of course, on some projects
even this is too big or expensive.

Quoted text here. Click to load it

The issue here is probably that a good eeprom ideally needs different
process parameters (such as number of layers, size of features, silicon
doping, etc.) than the rest of the microcontroller.  Often you can make
compromises, but you might find that to put an eeprom and a Cortex
microcontroller on the same die means sub-optimal setup of layers for
the rest of device (more power, more cost, lower speed, etc.).

Quoted text here. Click to load it

Some micrcontrollers (such as Kinetis) even have hardware to help this
process, though it is the same basic principle.

Quoted text here. Click to load it

That is not an obscure issue - it can be quite a relevant issue.  It
means that the timings for your flash-based data writes can vary
significantly.

Quoted text here. Click to load it

That's sometimes true - but some flash systems are more sophisticated.
Some devices have flash systems constructed from multiple (or at least
two!) planes, so that you can have read operations on one plane while
doing an erase or a write on the other plane.  And some have "erase
suspend" so that you can pause an erase operation and read from the same
flash plane (but a separate erase block), then continue the erase.  Some
even have a "write suspend", though I don't think I've seen that on a
microcontroller flash.  It should even be possible to automate such
suspension - in combination with an instruction cache, you could make
the flash erase and write operations almost unobtrusive (again, I don't
think I have seen that on any real microcontrollers - but I believe it
should be possible).

Quoted text here. Click to load it

It sounds like the device has two flash planes, and lets you read the
main program area while the data area is being erased or written.  It
won't let you do the reverse - that's just to simplify the flash
controller, since it is unlikely that accessing data flash would be
useful while the program flash is inaccessible.

Quoted text here. Click to load it

Yes, that's it exactly.


Another solution that can be useful in some systems is to have either a
small battery, or a large capacitor to give you some extra
microcontroller time after power is disconnected.  Then you can keep
your parameters in ram, and only save them to flash on power failure.
If you already have a battery for an RTC, then this might be a good
solution.



Re: Read-While-Write Flash memory
Il 15/08/2016 10:21, David Brown ha scritto:

Quoted text here. Click to load it

What about watchdog that triggers automatically a reset?

Usually the RTC battery supplies only the RTC and not the entire  
microcontroller, so that battery can't be used to "give extra  
microcontroller time".

Sincerely I will be worried to keep many persistent variables in RAM for  
days or months without saving them to a non-volatile memory, with the  
hope that they will be saved at the next power failure.


Re: Read-While-Write Flash memory
On 15/08/16 16:02, pozz wrote:
Quoted text here. Click to load it

What about it?  I don't see the connection.

Quoted text here. Click to load it

That all depends on how you lay out your board.  With a few external
components, you could use your RTC battery to power the microcontroller,
but not the rest of the board, when external power fails.  Once you have
saved the necessary state in flash, you can either disconnect the
battery from the microcontroller's main supply, or you could even simply
put the microcontroller into very low power-down mode.  It will use a
little more battery power than the RTC alone (a switch here would have
leakage, and even the very low power modes take /some/ current), but
maybe it will be small enough - I would guess that a 2 cm coin cell
could easily last a decade.

Quoted text here. Click to load it

It all depends on the application, and the importance of the data.  If
the data is the result of a time-consuming calibration process, then you
definitely don't want to risk it.  But if it is the user's last choice
of radio channel, then there is no problem.

This was not a recommendation for your application - it's just another
idea for a different way to handle such issues.



Site Timeline