1. Home
  2. Embedded Programming
  3. Read-While-Write Flash memory

Read-While-Write Flash memory

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]
formatting link
Reply to
pozz
Loading thread data ...

Yes.

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

Reply to
raimond.dragomir

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

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

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

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.

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

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.

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.

Reply to
David Brown

Il 15/08/2016 05:51, snipped-for-privacy@gmail.com ha scritto:

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

formatting link

Reply to
pozz

Il 15/08/2016 10:21, David Brown ha scritto:

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.

Reply to
pozz

luni, 15 august 2016, 16:50:45 UTC+3, pozz a scris:

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.

Reply to
raimond.dragomir

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

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.

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.

Reply to
David Brown

When the watchdog triggers, it automatically reset the microcontroller without saving the persistent parameters.

Yes, it is a possibility. Thank you for the hint.

Reply to
pozz

Il 15/08/2016 16:37, snipped-for-privacy@gmail.com ha scritto:

I think now Microchip is pushing up the prices of Atmel products.

Reply to
pozz

If your watchdog ever triggers, your system is broken. The watchdog is there to limit how bad the breakage is, but it is not something that should normally occur.

But as noted before, there are some types of parameters that are so important that you would not want to risk losing them if your watchdog /did/ trigger for some reason.

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.