How FRAM Memory Simplifies Embedded System Data Logging
I’ve always found it easier to make decisions when the options were clear cut. Choosing between black or white, right or wrong, you could make your decision and never regret it. However, decisions that involve picking black, white or one of many shades of gray really stress me out. I was happy abiding by my binary logic until Ferromagnetic Random Access Memory (FRAM) came on the commercial market and I was forced to embrace one of the shades of gray.
Up until this point, my only choices of data logging hardware for embedded systems were Static Random Access Memory (SRAM) and Flash. Those of you who worked in the pre-FRAM era probably understand my struggle to compromise SRAM data integrity issues with Flash’s relatively low write endurance. For those of you who don’t, let me explain...
How FRAM Compares to SRAM And FLASH
I initially came across FRAM in 2005 and was captivated by its characteristics. The cost of implementation was high so I had to wait 3 years until I could use FRAM in my designs. Before I start glorifying its merits, let’s take a quick look at SRAM and Flash, both popular memory chips in their own right.
SRAM is a form of volatile memory. This means that data stored in the memory is erased when the power supply is removed or cut-off. The great thing about SRAM is that it has an unlimited write-cycle, meaning it does not physically deteriorate as it is used.
Don’t Let Your Data Be At The Mercy Of A Tiny Battery
On the other end of the spectrum lies Flash memory, a non-volatile memory. This makes it particularly useful for storing transaction logs that must remain intact, even when the power supply is removed. The only downside to it is the low write endurance, which is often in the tens of thousands. Once it has reached this limit, any further attempts to write will not register in the respective memory cells.
FRAM is a memory chip that inherits the advantages of both SRAM and Flash memories. FRAM is a non-volatile memory that has an extremely high write endurance. It currently supports billions if not trillions of write cycles. Even better, the cost of FRAM has dramatically decreased as the manufacturing process of FRAM has matured. As one might expect, this has changed how data logging architecture is designed in embedded systems.
The Importance Of Data Logging in Embedded Systems
Reliable data logging capability in embedded systems has always been mandatory regardless its application. For example, fire alarm systems require all events to be properly logged in case of an audit, and attendance management systems require accurate logs of employee movement within the premises in the hardware controller.
Data integrity is the next most important thing than sounding the alarm.
While most electrical designers have no problem implementing an accurate data logging architecture, preserving the integrity of the data in the event of power failure is a common challenge. The same can be said about ensuring that the lifetime of memory chips are extended to their maximum.
How FRAM Changes Datalogging Designs In Embedded Systems.
A great way of visualizing data logging is to think about the thousands of books in your college’s library. Retrieving your favorite Harry Potter book will take less than a couple of minutes when everything is properly organized. However, if the shelves suddenly don’t have labels or the books are misplaced, then you’re in for a long tedious search. In embedded systems, tens of thousands records are stored in the memory, and they are constantly being retrieved by software applications to an external database. That means the microcontroller (MCU) itself has to be intelligent enough to keep track on the newest and oldest data and mitigate what happens when the memory is full.
Data logging is simple until you start losing track of the records.
The old and simple way to do this is to store all the transaction logs in a battery backup SRAM, and to allocate a few data pointers that keep track of what has been logged what has been retrieved by the software. The limitation of this approach is that the data integrity is 100% dependent on the backup battery. This means that you need to cross your fingers and hope that your battery is still alive if the system experiences a power failure or generic hardware failure.
On the other hand, Flash memories eliminate most data retention concerns. While transaction data can be stored in the Flash memory, data pointers still need to be stored in battery backup SRAM. Either that or you might risk damaging the individual Flash memory cells that have low write endurance. Alternatively, firmware developers could implement a sophisticated data management algorithm. This removes the need for data pointers but can overcomplicate the whole system and introduce unnecessary bugs.
When FRAM became a commercially viable electronics component in the late 2000s, data logging became ridiculously simple. Data pointers could be saved in FRAM without the fear of power loss corruption or physical deterioration to the memory chip. Since then, FRAM and Flash have been prominent in my embedded system designs that include process monitoring controller tracking and logging operations of multiple machines.
Does this mean FRAM will totally replace Flash and SRAM? It depends. FRAM does a better job in the areas that Flash and SRAM struggle. Its ability to retain data while ensuring a long life cycle makes it the ideal choice for applications that require storing configurations and dynamic records. That being said, Flash is still the better choice for storing huge transactions since its capacity is way higher than FRAM’s.
As for SRAM, I have completely stopped using it in my embedded systems designs. As a result of the decreasing cost of FRAM and its non-volatility, as a whole, it outweighs the benefits of SRAM’s unlimited write cycle. I do make one exception, though, for embedded systems where the microcontroller needs to boot from an external SRAM.
Are you designing data sensitive hardware and wonder if data integrity issues could haunt you after deploying hundreds of units in the field? Professional software like Altium’s CircuitStudio can help get you started.
Have a question about FRAM? Feel free to talk to our team at Altium.