We are currently poised at the beginning of an exponential increase in the deployment of sensors and microcontrollers (MCUs) for a wide range of applications, including smart utility metering, wearable electronics, data acquisition systems, and industrial and remote control systems.

A modern factory, for example, contains numerous building automation systems and data acquisition systems, all involving sensors and MCUs as illustrated below:

Similarly, a modern home features an ever-increasing number of security and automation systems, and — once again — these all involve sensors and MCUs as illustrated below:

A major consideration for all these systems is reducing power consumption and increasing reliability as much as possible. Designers are driven to add functionality while simultaneously reducing the system’s power budget — at the same time, embedded software is becoming larger and more complex, requiring more memory and further stressing the power budget.

The majority of today’s MCUs come equipped with two sorts of memory: Flash and SRAM. The Flash is relatively slow and supports a limited number of write cycles, but it is non-volatile and so is used to hold the code. By comparison, the SRAM is fast and has unlimited write cycle endurance, but it volatile and can only hold temporary data.

All of this furthers the complexity of the designer’s choice of MCU — how much Flash is required (how little will suffice)? How much SRAM will be needed (how little can one get by with)?

In order to address all of these issues, Texas Instruments (TI) has developed a line of FRAM-based MCUs. The original family was the MSP430FR57x series of devices. Now, TI has introduced two new families: the MSP430FR59x series and the MSP430FR69x series.

FRAM conveys many advantages, including the fact that it is non-volatile, which means it can maintain both code and data when power is removed from the system. Unlike Flash, FRAM has an extremely high write speed, it’s bit-wise programmable, and it can be written to an unlimited amount of times. Unlike SRAM, FRAM is non-volatile and it’s not susceptible to soft (radiation-induced) errors.

Another key consideration is that the FRAM simplifies the software architecture by allowing flexible code and data partitioning coupled with fast writes and unlimited endurance (FRAM does not require pre-erase and is the only non-volatile embedded memory that can be written at 8MBps).

This means that the same FRAM-based MCU can be used to address both “code-heavy data-lite” and “data-heavy code-lite” applications.

One more piece to the puzzle is TI’s EnergyTrace++ technology. Developers of embedded systems with low power budgets typically spend a huge amount of time figuring out where power is “leaking” out of their system. As illustrated in the image below, traditional debug systems — which are expensive and incompatible — are difficult to use, are limited by a one-way data flow, and don’t provide visibility into real-world MCU activity.

In order to address this, TI’s EnergyTrace++ technology enables developers to analyze power consumption in real-time for each peripheral, thereby allowing them to make intelligent decisions about code execution and to optimize peripheral use based on the power profile.

Costing less than US$30, EnergyTrace++ technology provides a closed-loop seamless integration of the IDE, tools, and devices, thereby resulting in embedded systems that are optimized for the lowest-possible power consumption.

Please visit the TI website for more information on EnergyTrace++ technology, the MSP430FR59x and MSP430FR69x MCU families, and the new low-cost MSP430FR5969 LaunchPad development kit.

— Max Maxfield, Editor of All Things Fun & Interesting

Max covers programmable logic, microcontroller units, and prototyping for EE Times' Designlines. Over the years, he has designed everything from silicon chips to circuit boards, and brainwave amplifiers to steampunk "Display-O-Meters." He has a BSc in Control Engineering in from Sheffield Hallam University in Sheffield, UK.

Max covers programmable logic, microcontroller units, and prototyping for EE Times' Designlines. Over the years, he has designed everything from silicon chips to circuit boards, and brainwave amplifiers to steampunk "Display-O-Meters." He has a BSc in Control Engineering in from Sheffield Hallam University in Sheffield, UK.

I didn't think that's enough to even advertise. 16KB is not even a usable text file.

@resistion I didn't think that's enough to even advertise. 16KB is not even a usable text file.

Who said anything about text files? It's plenty for lots of 'embedded' applications. I used to program Motorola 68HC705K1's 504 bytes of eeprom/otprom and 32 bytes of ram.

@Wnderer: I used to program Motorola 68HC705K1's 504 bytes of eeprom/otprom and 32 bytes of ram.

You had 32 bytes? You were lucky! We used to dream of 32 bytes LOL

I agree -- 16KB might not sound much to some youngsters, but it goes a long way if you know what you are doing.

Seems like a good combination of features for the applications mentioned, sensors, home security, etc.  Is it missing anything you wish it had?

Given that most MCUs are (now) pushing MB use, I did find this quite light.

@Janine: Is it missing anything you wish it had?

I actually have a MSP-EXP430FR5969 LaunchPad fraturing one of these little FRAM-based MCUs sitting on my desk -- I just need to find the time to play with it to discover more.

I'd be interested to hear from other readers as to how they would use the non-volatile nature of the FRAM to do things differently to the way they would use traditional Flash+SRAM MCUs

The claim of unlimited endurance is disingenuous. Please provide real measured or guaranteed cycles. MRAM has this same marketing habit as well.

@resistion: 16KB is not even a usable text file .

Hang on -- 16KB is the max size for the old 57x MCUs -- the new 59x MCUs go upo to 64KB and the new 69x MCUs go up to 128KB

I think it has a shot at replacing SRAM but Flash is currently used for MB storage. MRAM is another candidate commonly proposed for the same purpose, because of its high (also not unlimited) endurance. Both can also be disturbed by cumulative if not direct reads. I wonder which would be the preference.

@Resiston: The claim of unlimited endurance is disingenuous. Please provide real measured or guaranteed cycles .

As I recall, the number they gave me was 10^15 = 1,000,000,000,000,000

My big concern is the write-ability: We've all had a pointer go blooie (which is less likely in high(er)-level languages like C than in assembler, but a 16k chip is probably going to see assembler). Do they provide some way to lock/protect the code portion of the memory?

@GSKrasle: Do they provide some way to lock/protect the code portion of the memory?

I don't know -- I'll ask them

FRAM based controllers from TI are really a very nice design and provide improvement both in terms of speed and power. Many small size embedded systems are adopting these controllers especially in biomedical equipments.

The devices in the MSP430FR59x/FR69x series can protect portions of code using a couple of built-in modules. The Memory Protection Unit (MPU) monitors and supervises memory segments as defined in software to be protected as read, write, execute or a combination of the three. What's more, these devices have built-in IP Encapsulation (IPE) capabilities to lock sections of code from access via JTAG, BSL or Direct Memory Access.

Up to 128kB might be more than enough for many applications.

If an application needs MBs go for an MCU with MBs and you can justify the cost. A smart sensor sitting remotely powered from <4mA in a 4-20mA loop or a smoke detector will never need MBs.

Each read takes a cycle as well, you still have to write after read.

@resistion: Each read takes a cycle as well, you still have to write after read.

But reading from any form of memory (Flash, EPROM, FRAM) doesn'd degrade it and doesn't count as part of the total number of cycles -- when they say Flash can support only 10,000 cycles, for example, they are talking about erase-&-write cycles, not read cycles.

@resistion: Each read takes a cycle as well, you still have to write after read.

You don't always have to perform a write after performing a read.

The read checks polarization by monitoring a particular write operation. When the polarization has been flipped, the original state has to be written back.

@resistion: The read checks polarization by monitoring a particular write operation. When the polarization has been flipped, the original state has to be written back .

Wow -- I learn something new every day -- thanks for sharing.

Of course there's been work to get around this but it's not standard FRAM.

You must Register or Login to post a comment.

This site uses Akismet to reduce spam. Learn how your comment data is processed.