Read and write flash memory


I have an arduino mega 2560 board. It has a 256kb flash memory(which includes 8kb bootloader). Is there any way to read and write the flash memory at a particular address. Can I divide the flash memory into two halves and dedicate one half for the program code + bootloader and the other half for general purpose non-volatile memory usage ?

Thank you.

If you rewrite the bootloader, yes, you can do that.

Is there any arduino tutorial that explains how to do this ? Please help.


The fact that you asked the question suggests that you probably shouldn't attempt to rewrite the bootloader. It's not a trivial task and if you screw it up, you could turn your Arduino into a silicon brick.

It’s not really an Arduino subject, IMO.
You’d be better off adding some other form of storage, like I2C EEPROM or an SD card.

See Section 29 of the datasheet:

The Boot Loader Support provides a real Read-While-Write Self-Programming mechanism for downloading and uploading program code by the MCU itself. This feature allows flexible application software updates controlled by the MCU using a Flash-resident Boot Loader program. The Boot Loader program can use any available data interface and associated protocol to read code and write (program) that code into the Flash memory, or read the code from the program memory. The program code within the Boot Loader section has the capability to write into the
entire Flash, including the Boot Loader memory. The Boot Loader can thus even modify itself, and it can also erase itself from the code if the feature is not needed anymore. The size of the Boot Loader memory is configurable with fuses and the Boot Loader has two separate sets of Boot Lock bits which can be set independently. This gives the user a unique flexibility to select different levels of protection.

The Application section is the section of the Flash that is used for storing the application code. The Application section can never store any Boot Loader code since the SPM instruction is disabled when executed from the Application section.

While the Application section is used for storing the application code, the The Boot Loader software must be located in the BLS since the SPM instruction can initiate a programming when executing from the BLS only. The SPM instruction can access the entire Flash, including the BLS itself.

The program memory is updated in a page by page fashion. Before programming a page with the data stored in the temporary page buffer, the page must be erased. The temporary page buffer is filled one word at a time using SPM and the buffer can be filled either before the Page Erase command or between a Page Erase and a Page Write operation:

If only a part of the page needs to be changed, the rest of the page must be stored (for example in the temporary page buffer) before the erase, and then be rewritten.

Boot size choices: 1K bytes, 2K bytes, 4K bytes, or 8K bytes (K=1024)

of pages:

Read-While-Write section (RWW), 992. 0x00000 - 0x1EFFF
No Read-While-Write section (NRWW), 32. 0x1F000 - 0x1FFFF

RWW – Read-While-Write Section
If a Boot Loader software update is programming a page inside the RWW section, it is possible to read code from the Flash, but only code that is located in the NRWW section. During an on-going programming, the software must ensure that the RWW section never is being read. If the user software is trying to read code that is located inside the RWW section (that is, by load program memory, call, or jump instructions or an interrupt) during programming, the software might end up in an unknown state. To avoid this, the interrupts should either be disabled or moved to the Boot Loader section. The Boot Loader section is always located in the NRWW section.

NRWW – No Read-While-Write Section
The code located in the NRWW section can be read when the Boot Loader software is updating a page in the RWW section. When the Boot Loader code updates the NRWW section, the CPU is halted during the entire Page Erase or Page Write operation.

So, what you seek in general is possible. Could lead to big performance hits as entire pages must be read, modified, and rewritten. I'm with AWOL, using an external device, I'd personally go with SPI interface for speed, would be way less complicated. SD card is only accessible via SPI interface. FRAM has speed of SRAM and non-volatility of EEPROM.

Thanks all for the reply.

I was going through and it has been mentioned that,

Note: Flash (PROGMEM) memory can only be populated at program burn time. You can’t change the values in the flash after the program has started running.

Actually, I was using SD card through SPI pins to save data in between the power cycles. But, due to some unknown reason after working for several days, SD.begin() is returning false making the micro controller not able to access the SD card unless I switch OFF the power to the mega 2560 board and switch ON.

So, I was curious if I could use the flash memory itself to maintain data between power cycles. But, it seems it could do more harm than good. My only option now would be to find out what is making the SD.begin() to return false. If it is due to any watchdog timer reset that I have in my code, I have to find out. Anyone having found solution to this issue of SD card could please help me ?


External EEPROMs (AT24 and compatible - a bunch of companies make them) are an option, though if your application is a datalogger, this isn't such a great choice, since you can't read them back from a computer.

I have seen a stunningly high rate of problems with sd cards. Sometimes it's a soft failure, and formatting makes them work again, other times, it's dead. It's not just in the context of Arduino that they're failure prone, but it seems to happen more when using with a microcontroller - not sure what we're doing that they don't like.


Is it possible to write in the No Read-While-Write section (NRWW) from an 'arduino sketch' ? Is there any lock bit to disable so that I can write in the NRWW section ? If someone could help me with the way to write in the NRWW section, my project will finish successfully. :slight_smile:


I think you would have to use code that is running in the bootloader area to do that. It's not a lock bit setting - it's a function of the SPM instruction, which can only execute from the bootloader area. See Section 29 as I referenced earlier.
You would likely achieve a quicker finish by adding an external EEPROM or FRAM accessed via SPI commands.
Some examples of 5V FRAM:

Thanks for the reply. If I could use the FRAM as suggested by you, I would have been back to home by now. :slight_smile:

For Arduino Mega 2560, the booatloader starts from 0x3E000 i.e, the last 8kb of the 256kb of flash is where the bootloader resides. In that case, the memory starting from 0x00000 to 0x3DFFF will be considered as Read-While-Write section (RWW). Can this memory be accessed from Arduino sketch to write into it ? If yes, please explain the steps.


Can this memory be accessed from Arduino sketch to write into it ?



recently i also debugging with the memory writing in sketch, i can read successfully,but cannot write the memroy. i wonderring if it can be writed! but why it cannot be writed in the sketch?

but why it cannot be writed in the sketch?

Because that would open up whole new exciting routes to hair-loss.

C already hands you the gun, loaded, a round in the chamber, cocked and with the safety off.

If I want to change the starting address of bootloader from 0x3E000 to 3C800(Moving up 6kb) so that I can add some functionality in the bootloader, what are the changes I need to do in the bootloader code ? Any fuse bit need to be changed while burning the bootloader ?


This seems related:

Enough of this how do you write to the flash. Why do you want to do this?


Is it possible to write in the No Read-While-Write section (NRWW) from an 'arduino sketch' ? Is there any lock bit to disable so that I can write in the NRWW section ? If someone could help me with the way to write in the NRWW section, my project will finish successfully. :slight_smile:


I suggest you solve your problems with the SD card. The flash has a limited number of read/write cycles. Branching out into writing into the flash is likely to be much more complex than working out why the SD card isn't working.

I don’t see any posted code. Therefore this is not a programming question. I am moving this thread to Project Guidance.