FRAM or flash: How to select the right MCU for your application

When choosing a microcontroller (MCU) to use in your application, you will have to decide between using a device with flash or ferroelectric random access memory (FRAM). You might be wondering what FRAM is and if it’s a worthwhile feature. FRAM offers several advantages over traditional memory technologies such as flash, including faster write speeds, unified memory, low energy writes and there is no need for pre-erasing. These advantages directly translate into real function-level benefits in low-power applications.

Consider an application that requires firmware updates in the field such as over-the-air (OTA) updating. Let’s say that you need to transfer a 4kB firmware image into memory via Serial Peripheral Interface (SPI) and are debating between using flash or an FRAM-based device. A quick experiment using the same SPI settings for both an FRAM and flash device shows the immediate benefit FRAM has over flash in this application. Table 1 details the devices used as master, slave, the SPI clock rate and the total amount of data transmitted in this application.

Master

Flash slave

FRAM slave

Serial clock

Total data receiver/transmitter

MSP430FR4133

MSP430F5529

MSP430FR5969

 

1MHz

4,096 bytes

Table 1: Application hardware and SPI setup

The time saved using FRAM is apparent in Figure 1 below. Imagine being able to update your firmware 16x faster! This is one of the fundamental values FRAM provides over flash in this application. Notice how the FRAM write time is roughly the same as the SPI transfer time for the flash use case. This is no coincidence. In fact, the majority of time spent “programming” FRAM in this application is actually spent transferring the data over SPI. Overall, you can write FRAM at speeds much greater than 1MBps and 100x the write speed of flash.

Figure 1: 4kB firmware update speed

You can also see that a large portion of the time consumed on the flash device is spent erasing the old firmware, whereas FRAM doesn’t require this pre-erase. By eliminating the memory erase time, you also eliminate the energy bottleneck associated with flash technology. For comparison, check out the energy consumed during the flash and FRAM updates in Figure 2.

Figure 2: 4kB firmware update energy consumption

Here is another example of FRAM’s superiority over flash. Measured one of TI’s LaunchPad™ development kits, the FRAM device consumed 21x less energy than the flash device when updating 4kB of memory. This type of energy savings can increase an application’s battery life drastically and doesn’t just benefit OTA applications, but remote sensing and data-logging applications as well.

One of the greatest benefits FRAM provides in this application is unseen and often overlooked. To program a “1” in flash, you first need to perform an erase. The smallest amount of memory that can be erased when using flash is called a segment, and on an MSP430™ MCU, a segment is 512 bytes. Figure 3 shows a similar application where you only want to update 1.25kB of the firmware instead of all 4kB.

Figure 3: Partial segment firmware update

From the viewpoint of FRAM, this application is almost no different than updating the entire firmware. Conversely, this is no trivial task for flash due to segment boundaries. Figure 3 shows how the firmware update splits segment No. 4 in half. To program this segment, it must first be erased entirely. So how do you keep the rest of the code in the segment intact? You’d have to copy the segment into RAM, combine it with the new update and then program it back into flash. This requires a significant amount of RAM, increases time and adds complexity to the update process that would be completely eliminated when using FRAM.

In conclusion, FRAM technology offers benefits for a variety of applications. The fast write speeds, unified memory, high endurance and low energy consumption are setting a new standard for MCU memory and enabling innovative solutions worldwide. You can quickly evaluate or start rapidly prototyping an FRAM-based solution using one of the MSP430 MCU FRAM-based LaunchPad development kits. These kits offer everything necessary to get started developing for under $20, and are available through distributors and the TI store.

Additional resources

  • Just some remarks regarding numbers on Fig 1. MSP430F5529 flash block write can go over 100 KByte/sec without smart bit enabled, or over 200 KByte/sec with smart bit enabled. It is far away from presented 4 KByte / 289 ms = 13.8 Kbyte / sec. Mass / bank / segment erase will not take more than 35 ms (that is far away from presented 206 ms). I agree that working with FRAM regarding write (without erase) is more simple, but don't see reason for downgrading your own device with flash (MSP430F5529) just to FRAM numbers look nicer.

  • Hi zrno,

    Thanks for your feedback and keeping me on my toes. You bring up some valid points and it looks like some clarification on how the application was setup is necessary. This target devices is setup to receive a packet of information including the start address, length, and payload (512 bytes) via SPI and temporarily store this data in RAM. Then a segment erase occurs on the flash segment containing the start address. In this scenario there are 8 segments, 8segs * 32ms = 256ms max erase time. Then the segment is programmed via byte writes, 4096 bytes * 85us = 348ms max write time.

    You're correct that the erase time can be decreased by using either a mass erase or bank erase. A mass erase can't be used in this application because the bootloader is implemented in main flash space so that SPI communication was possible. A bank erase was not used because it would require erasing 32KB just to update 4KB of memory. This would have effectively rendered the leftover 28KB as unusable code space.

    You're also correct that the write time can be decreased by performing block writes instead of the byte writes used in this application. The bootloader used in this application was based on MSPBoot which only uses byte writes. I see no reason for not using block writes in this application and intend to update both MSPBoot and this blog post with this feedback.

    I agree that the techniques you've described could improve the flash write and erase times but wanted to make clear why they were not chosen for this specific example. You've also shown there are several different methods for programming/erasing flash on MSP430 devices which adds complexity that would be non-existent when using a FRAM device. Thanks again for your feedback and interest!

    Best regards,

    Caleb