How to Select the Right Amount of Flash Memory

Selecting the right amount of flash memory for an embedded application can be challenging. You want to make sure that you have enough memory to protect for future features, firmware updates, and more. Yet, at the same time, even though memory is “cheap,” you don’t want to overdo it. 

Your product might be manufactured in large volumes, which means every penny you save can have a major impact on the financial success of your company. In some cases, that could be the difference between a stable and successful career at the company, or a stressful, turbulent one. 

Let’s examine several best practices for selecting the right amount of flash memory for your embedded application. 

Differentiate Between Memory Types 

Before you select your memory size, it’s important to differentiate between the different types of memory you might be selecting. While there are different types of flash memory and RAM, we’ll be looking at a very simple type: internal versus external memory. 

Internal flash memory is the memory that is on-board your microcontroller. When you go to your favorite supplier and look up microcontrollers, you’ll find that they come in different sizes with various memories. Internal memory is used to store data such as:

Related:Flash memory for software-defined vehicles?

External memory is the memory that is off board your microcontroller. You select this memory separately from your microcontroller. It is usually connected to the microcontroller through QSPI, SDHC, and so forth. External memory is often used for:

We’re specifically going to look at the best practices for selecting the flash memory on-board a microcontroller. 

Start With a Draft Memory Map

When you first start a new project, you basically have no clue how much memory you are going to need. Your application is going to consist of:

It’s tough to get a feel for how much flash space you’ll need, especially since you may need extra space to store a spare firmware image and future features that are added after the product is launched. However, you can get an initial estimate that will help you determine the baseline or minimum amount of flash you’ll need. 

Nearly every microcontroller vendor provides some type of configuration tool. Those tools are designed to help you get up and running on the microcontroller fast! You can quickly configure an RTOS, set up USB or a file system, and so forth. When I’m saying quickly, we’re talking an hour or so. 

Related:Memory Suppliers Upgrade RAM Performance

You can use the microcontroller configuration tools to build out a quick application that roughly gets you your minimum flash usage. You’ll also have a general memory map if you look at your .map file that tells you how big each library is. 

“What good is the minimum?” you might think, but the minimum will help you to constrain what memory sizes you should be looking at. It gets you the lower end boundaries for what will be acceptable. 

With the minimum and the default memory map, you can build on the memory map to estimate additional memory that would be needed. I would include things like the application, application image spaces, and so forth. 

Start With Pin-Compatible, “Big” Memories

Once you have the lower boundary for your memory usage, you’ll need to identify the top-end. That’s where the real work needs to be done. The general rule of thumb is to start developing your application, using the largest memory footprint in the microcontroller family you selected. 

You must be a little bit careful, though, that you don’t box yourself in. While developers might be using the largest memory parts to get started, the hardware team at some point needs to constrain the hardware design. The best way to do this is to identify microcontrollers that have pin-compatible parts. 

Related:Video: How Does DRAM Work?

For example, you might pick vendor A’s family B microcontrollers that offer 50 different pin-compatible parts that range from 32 kB of flash up to 1 MB. If the pins are compatible, the hardware team can design the hardware while the software team works on the application and quantifies how much memory they really need. 

Quantify Your “Extra” Spaces

To some degree, the biggest challenge with selecting your flash memory size isn’t your application. It’s determining how much extra space you want to leave for future features, bug fixes, and firmware updates. 

My general rule of thumb has always been to ensure that an application has at least 20% free flash space. Unfortunately, that 20% is just an arbitrary number. I’m not aware of any study that has looked at embedded applications and determined how much additional memory is used over the product's lifetime.

That means again that you must examine your product roadmap to determine how much extra memory you might need. Typically, the initial launch contains the most features. It’s the minimum viable product (MVP), but that minimum will use the most significant amount of flash memory. 

It would be best to estimate how much extra space you’ll need based on the size of your current application and the expected number and type of additional features that will be added to the product. If you add little valuable features for the customer, then 20% is probably plenty. However, if you plan to launch and add machine learning, that is an entirely different scenario. You might need to ensure you have one to ten times as much memory available.

Firmware updates can also dramatically impact the flash size you select. One potential design pattern is to store two images internal to the microcontroller. That means that if your total application fits within 128 kB of flash, you’ll need an additional 128 kB of flash to store any new images! 

For a microcontroller, the internal flash is often much more expensive than the external flash. Therefore, we typically use an external flash to store images that can be transferred to internal memory during an update. 

As you can see, deciding how much extra space you need greatly depends on what you will do with your system after deploying it. You may find that 10% is enough or you need 100% or more extra space. 

Taking Your Next Steps

In this post we’ve explored several best practices for selecting the right amount of flash memory for an embedded system. These best practices have ranged from generating a memory map early in the development cycle all the way to leaving 20% of free space once your application has been completed. 

The exact details of what is right for your application will vary based on your end goals and objectives. There really is no one-size-fits-all methodology or guidance that can be applied. However, the best practices discussed in this post can help give you some ideas and get you closer to selecting the right size flash memory for your embedded system.