Is flash memory in MCU's similar to a hard disk?

Question

I have taken a Computer Architecture course in the past that focuses on desktop CPU's and I currently work in embedded systems and I am kind of confused as to which memory corresponds to what.

I am trying to create in my head an analogous image of the one of the desktop CPU's and I can't find something that I am really confident in.

For example both microprocessors and MCU's have RAM memory which is fine. From my understanding this is the immediate memory that the CPU can access You could use virtual addresses of course and have access to all the data but in effect you would have to move it to cache and memory first in order for it to be accessible by the CPU.

Does this mean then that flash memory inside an MCU is similar to the hard disk of a computer?

And if so then what is the role of an EEPROM?

Thank you very much for your help.

Answer 1

Flash is is like a hard drive because:

• It is nonvolatile, meaning it retains it's contents while power is removed.
• It's where the executable program is stored.
• It can be erased and reprogrammed.

Flash is not like a hard drive because:

• The microcontroller CPU typically has a parallel interface to flash and can address it like RAM.
• The microcontroller CPU can typically execute code directly from flash, without first loading it into RAM.
• A file system is not typically implemented in flash (although sometimes a file system is implemented on flash).

The PC's BIOS ROM, rather than the hard disk drive, is probably a better analogy for a microcontroller's flash.

EEPROMs are also nonvolatile like flash. These days microcontrollers typically use flash memory for program storage. EEPROMs are typically accessed serially, are typically smaller than flash, and are often used to store configuration settings and such. (I say "typically" because these aren't absolute rules.)

Answer 2

There are two kinds of flash memory: NOR flash and NAND flash. NOR flash has a parallel interface for address and data, just like normal RAM, and is typically used as part of the memory space of the microcontroller.

So you can typically execute code out of NOR flash. NOR flash is typically contained with the microcontroller chip, and in fact that is how virtually all of the microcontrollers store their code; or it can be external, extending the memory space of the microcontroller. However this require an external address and data bus, which takes a lot of extra pins on the microcontroller -- often replacing pins that are used for I/O ports.

NAND flash, on the other hand, is almost always external to the microcontroller, and is more like a flash drive that you would plug into a USB port on a PC or laptop (although if NAND flash were interfaced directly to the microcontroller, there would be no need for the USB interface).

The most important thing about both types of flash memory, is that reading is much much faster than writing. So you cannot use it as an extension of RAM. Reading is done just by accessing the memory directly. Data can be read one word at a time, where a word is defined as the data width of the microcontroller, typically 8, 16, or 32-bits.

However programming gets a little more complicated. The default state for NOR flash and other non-volatile memories like NAND flash, EEPROMs (Electrically Erasable Programmable ROM)and even EPROMs (Erasable Programmable ROM) is a logic 1. You cannot program 1's into these devices, you can only program 0's. So for example if you have a byte containing 0x0123 and you want to change it to 0x3210, you can't do so directly like writing over a byte in RAM.

Instead, bits in the memory must be erased, which puts them into the default 1 state already mentioned. This can only be done in blocks, not words. On the Microchip PIC32, which I have worked with the most lately, the minimum block size that can be erased is 4096 bytes. So if you wanted to change just one word (32-bits), you would have to read the 4K of memory, erase the block, then write the 4K of memory back to flash but including the new 32-bit value as needed.

This erasing takes a lot of time -- tens or even hundreds of milliseconds. So it is not usable for read/write memory like RAM. The erasing writes 1's to all bits in the block. After the block has been block eraeed, it is then possible to write to it. Writing can only write 0's to the flash, 1's are ignored since the block has already been erased to 1's. One a bit has been changed to a 0, you cannot change it back to a 1 without doing the erase operation.

Most microcontrollers use what is called a programmer to initially program the code into the chip. Once it is programmed, it is ready to execute code. Most programs do not changes the contents of the flash memory used for code, although it is usually possible to do so.

This block erasing of the device goes back to the first EPROMs, which proceeded EEPROMs The code was programmed into chips (like the 16KB 27128) and placed in sockets. These chips had a little window on top which allowed light to shine on the die. When the program had to be changed, the chips were put into a UV eraser for 20 minutes or so, which would erase the entire chip. Then the chip would be programmed with the new program.

Some EEPROMs require erasing of blocks of memory before programming; others allow writing a byte at a time (the EEPROM controller actually erases the byte first and the programs it).

The useable life of non-volatile memory is measured in terms of erase cycles. The disadvantage of NOR is that the number of erase cycles is about 1/10 that of NAND memory. Many versions of the PIC32 only allow the flash memory to be updated 1000 times, way less then the typical 100,000 erase cycles for EEPROMs or NAND.

Answer 3

It's a bit bothersome to compare an embedded controller like an MCU to a full and complete computer or even just the main board.

In some senses you can say that Flash behaves a bit like a Hard Disk and that RAM behaves like RAM and that registers can be seen as a sort of Data Cache, but there are some very vital differences.

For example many MCUs have a very limited start-up behaviour that just starts executing commands at the beginning of the internal Flash memory. If the very first byte is some random data inside what could be an Excel file, that would be bad. Some MCUs can also write to the Flash, some can't. In many designs the Flash is used as a true ROM, you can program it often, but the normal application code can't or won't (a firmware updater would, of course, but that's a special use case). In a PC the processor isn't even the first thing that starts working, it's the BIOS. The BIOS is a sort of MCU that looks for a Hard Disk (or other device), then looks for a Bootable drive on that Disk and then tells the CPU to start working from there. And also performs a load of other functions on motherboards these days. Thanks to brhans: The CPU does start working right away, but loads its initial operation, or at least in most cases, from the BIOS (E(E))PROM to start figuring out itself where to find stuff in the system. It then searches a real bootable medium and loads the OS from there. Such as a USB stick, Hard Disk or CD-ROM.

Apart from that your MCU very likely has a very intimate relationship with its internal RAM, you can basically read and write any byte to your heart's content (including the , while most, if not all, computers would have exclusion zones (managed by the memory controller) or even full protection where you need a special privilege (such as being the currently running operating system) to access the memory directly.

Most MCUs have no instruction cache, they just load the instructions from Flash, one by one, progressing to the next byte/word by simply increasing the program counter, where a CPU would load a chunk of program (or sometimes all of it) from the Hard Disk into RAM to be able to access it quicker, and then to access it real quick would load smaller bits from the RAM in blocks into the instruction Cache. If a computer would load its CPU instructions from the Hard Disk directly we would probably only have started using any kind of "Windows 95" type OS at the advent for Solid State Drives, because running a full graphical OS like that and still doing something else from an ATA133 Hard Disk would be a challenge, to say the least. Let alone slower types.

In MCUs the EEPROM can be seen as the dedicated data storage. Where in a PC the Flash and EEPROM functions are both hosted by the Hard Disk, storing both Data and Programs, in many Embedded Systems the Flash (as mentioned earlier) is only used to store the program and fixed numbers that the MCU won't change, but only uses or looks-up, while the variable data is stored in the EEPROM.

Of course, that's a generalisation, there's plenty of examples where some data is stored in the program Flash and still changed by the normal program regularly, but in most cases that's not an entirely great idea. (The Write endurance of Flash is lower than EEPROM, for one).

There's doubtlessly many more examples of differences that don't just pop into my head right away, and possibly I have made a few tiny mistakes along the way, but I hope at least there's a bit more clarity about some of the more major differences. There are some similarities, but they are most certainly not the same.

Answer 4

TL:DR; Would say the flash is the SSD rather than a HDD.

First of all: Neither of the two, flash or eeprom, have moving parts inside them, so there arent a Hard Disk (HDD), but rather an SSD.

Back to Topic: The Flash is moreover the primary SSD in your system, the boot device. Because the flash is the part of the MCU which is responsible for controlling it, with which you can f.ex. display things, like on a PC.

But with one difference: The Flash cant (As far as I know) change itself. Whereas on a PC you can also store data on your primary Storage Device.

Thats where the EEPROM comes for: You could say its either the rewritable part of your normal Storage Device or your secondary Device.