4
\$\begingroup\$

Information show that flash memory have a limited number of write cycles (usually ~10'000). Many MCUs emulate EEPROM in flash, hence some document this write_life_cycle.

A look at any MCU datasheet reveals something odd though - this flash memory is just a bank in the MCU memory unit. It shares the overall memory with "control and data REGISTERS" (see attached photo).

Hence my question: Suppose a program continuously writes to these registers (eg const ADC temp readings written to ADC1_DR), then this write_life_cycle may be exceeded in under a second. However, as we know MCUs outlive that by some margin.

I tried to assume that maybe, registers are implemented differently in HW, but then, why would their memory addresses overlap with the flash space and their widths be same?(a 32 bit bus can obviously access an 16 bit register -> case in point: all those reserved bits in some registers; might even reduce cost)

What have I got wrong in my understanding of how MCU memory works?

STM32F10xx_MemoryMap

\$\endgroup\$
  • \$\begingroup\$ I would think that MCU registers would be in RAM, or dedicated hardware registers. You might store program code or data in flash, but you wouldn't be constantly accessing it (and it would be very slow). Peripherals are included in the memory map, but aren't actually in physical memory. \$\endgroup\$ – uint128_t Feb 18 '16 at 3:38
  • \$\begingroup\$ "their memory addresses overlap with the flash space" - what overlap? \$\endgroup\$ – Bruce Abbott Feb 18 '16 at 5:34
  • 1
    \$\begingroup\$ The flash memory back you see in the memory map is read-only! To write/erase flash, the program must do operations to control registers. You need to read up on how NOR flash works. In a nutshell, write operations only turn one bits into zero bits. Erase operations turn entire pages of bits to all ones. In general, the cycle restriction is actually on erase cycles on each page but you can write to a page as many times as you want (but this cannot return 0 bits to 1). This allow you to do writes to successive bytes/words without using up cycles. \$\endgroup\$ – DoxyLover Feb 18 '16 at 5:40
  • \$\begingroup\$ @BruceAbbott In the datasheet of the MCU. It is stated that all cortex m series MCUs come with the flash of fixed size 4GB (some blocks of it are reserved for future use ie new added peripherals, while the blocks needed for implemented peripherals are dedicated. \$\endgroup\$ – haxkalibrr Mar 16 '16 at 18:08
4
\$\begingroup\$

Modern processor architectures allow you to address a contiguous memory space with the same data bus, even when you are accessing multiple types of memory (e.g. RAM, ROM, and Flash). As it turns out, this is quite handy as it allows your program to read/write RAM and read from Flash without doing any special tricks to switch memory types.

This is the same principle as an external data bus that can access a discrete RAM chip within a certain address range and a discrete ROM chip within a different address range, even when both chips are on the same bus and within the same address space.

On a modern microcontroller, these RAM/ROM/Flash sections are all included together on the same part and may be accessed by the same data bus within the processor.

Function registers are in RAM, and may be read/written as much as you'd like with no penalty. Your example of an ADC register that is updated constantly is a good one; RAM is used to store the ADC results in that register and it can be accessed on the same data bus with the flash memory.

Program code is usually in the flash space, and this is (usually) read-only. However, some processors do allow you to erase and re-write sections of the internal flash memory. This isn't as easy as writing to RAM; there are usually some special instructions that tell the processor which page to erase, etc. Most vendors will provide a library and/or example code to do this, as in the case of an EEPROM emulated flash area you mentioned.

In most microcontrollers, writing to flash is the "easy" transition (1s get changed to 0s) and can be done on a byte-by byte basis. Erasing (0s back to 1s) is not so targeted and is typically done in blocks (page, sector, etc.) Since this erase requires a higher voltage, there is an on-chip charge pump to generate this flash erase voltage.

This higher erase voltage has two consequences: erase cycles are typically much slower than reads (a charge must be built up and the erase must be verified), and the high voltage pulses do wear down the flash a little with each erase cycle. Thus, erasing flash should be done sparingly.

You are right that vendors build in margin to these life estimates, but you should take care when designing an application that erases/writes to flash (self-programming) so that you do not wear out your flash memory before your product has exceeded its design lifetime.

\$\endgroup\$
  • \$\begingroup\$ That was concise, thanks. So, it really is implemented differently in HW. I didn't know its internal memory works like just adding external memory. That would mean that all those reserves I see might actually not even exist, but represents the band gaps in the various addresses. \$\endgroup\$ – haxkalibrr Feb 19 '16 at 0:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.