feature article
Subscribe Now

A Self-Sufficient Serial Flash Memory

Adesto’s FusionHD Flash Unburdens the CPU

For IoT devices, it matters that the system be able to power itself down when not doing anything. So it matters that critical data remain in place when power is off – meaning that it needs non-volatile memory. Which, today, would be flash. And serial flash can be a good way to add such a memory with a modest footprint.

But, let’s face it: serial flash devices are entirely submissive: they do only what they’re told, and they do it only when they’re told to. Want to store some data? You have to tell it what data to program where, then issue an instruction to program It, and then monitor progress. Except that, in this case, “you” isn’t you; it’s the CPU.

Traditionally, the CPU is total and absolute master, directing every last step that the flash takes. It has to micromanage every detail. And, by the way, you can’t store just a few bytes of data – say, the most recent sensor reading – if that’s all you need.

Traditional Flash

Or, at least that’s how it works with conventional flash. Let’s review that process, since it will illuminate some of the challenges that Adesto is addressing with their new FusionHD serial flash family. In order to maximize capacity, flash architectures make some tradeoffs. Here are some traditional assumptions:

  • You cannot program a flash bit cell more than once without erasing it first. If you do, you’ll over-program it, making it hard (or impossible) to erase reliably.
  • Programming happens a page at a time. You can’t address a byte and program only that byte. So if you want to change part of that page, you need to program the entire page, and that means “re-programming” bits that aren’t changing. Per the prior point, those bits need to be erased first.
  • Erasure happens on a block – which is larger than a page. You can’t erase individual bytes or even pages.

So that means, if you want to change only one byte, the CPU needs to:

  • Read out the current block contents to working memory
  • Change the desired bytes within working memory
  • Erase the block
  • Reprogram the entire block with the modified contents.

If you’re dealing with large chunks of data – say those cat videos you want to share – this may not be much of a limitation. Indeed, we’ve been successfully living with this for a long time now.

But what about the IoT? We’re not necessarily storing large chunks of data. We might be storing only a few bytes that represent some recent measurement. Is it worth the effort to redo a whole block (which could be thousands of bytes) to update just a few? It’s doable, but it’s inefficient. And, if long-term performance is considered, you’re rewriting many bytes many more times than would seem necessary, which shortens the life of the memory.

Finally, the CPU has to manage all of these details – including polling to determine when the programming operations are complete. That could take a while – time during which the CPU could otherwise be taking a well-deserved nap.

FusionHD

So, with that background in place, Adesto has announced their FusionHD memories. And they’ve taken several steps to make the architecture much more useful for small-data and low-power operation. Some key changes:

  • Individual 256-byte pages can be erased.
  • Internally, they can program, effectively, at the individual byte level.

They’ve then included two important features for allowing the CPU to hand off operations and go to sleep while they complete:

  • The device is capable of programming the contents of the SRAM buffer into non-volatile storage with no involvement from the CPU (other than initiation). This includes the pre-programming page-erase step.
  • The memory can interrupt the CPU when complete.

So there are two ways of programming this device. Programming an entire page will put the contents of the buffer into the designated page – after erasing the page. The device manages this itself; the CPU doesn’t need to micromanage it. Alternatively, if you want to change only some bytes within a page that’s already been programmed, you can make use of a Read/Modify/Write (RMW) command that, to the outside world, alters only bytes that are changing.

With a traditional flash device, programming starts automatically when the buffer is full. That’s not how FusionHD has to work. You can fill the buffer completely or partially and then issue a command to start the programming process. The CPU can also specify where to program the buffer, which allows wear-leveling, if desired (to ensure that all bytes get exercised and wear out evenly rather than just a popular few bytes).

However you program the device, the CPU no longer has to track the process. The memory chip effectively takes the instruction and says, “Got it. Go take a nap; I’ll wake you when I’m done.” And the CPU can sleep – or pay full attention to some other duty that calls – until interrupted by the memory. In other words, the memory is no longer entirely submissive: it’s got some level of self-sufficiency.

Programming can also be done very quickly, so that, in the event that power fails, the buffer contents can be quickly programmed to keep them from being lost during the outage. A local capacitor (with a diode to isolate it to the memory) can keep enough energy around to complete the programming before everything goes dead. This is in contrast to a traditional flash, where an entire block must be read, erased, and reprogrammed – not doable quickly.

The device also has a 4K-byte block that can be erased and programmed. But the CPU must be involved during that process to keep feeding the 256-byte buffer.

So you end up with a memory that’s much more amenable to storing small chunks of data – more typical of the IoT – while opening up the system for significant power savings – also a need for the IoT.

And Some Gravy

They’ve included a couple of other features in the device. They’re not really related to memory per se, but Adesto says that they’re helpful and inexpensive to implement, and they reduce cost and/or provide the CPU with yet more opportunities to sleep.

  • Direct connection to a battery, eliminating the need for a regulator or PMIC.
  • A battery monitor, measuring the voltage level and eliminating the need for a separate health monitor.
  • A system reset generator. The reset button can be connected to the flash device, with programmable button-press duration. The flash device will then hard reset the MCU if it hangs.

Finally, they’ve made a commitment to a long product lifetime. This is intended, in particular, to make these devices attractive to the medical market, where development and approval times can be long and where equipment might also have a long lifetime.

 

More info:

Dual/Quad SPI Memory

Sourcing credit:

Graham Loveridge, Senior Director of Marketing, Memory Products Division, Adesto

Paul Hill, Sr. Marketing Director, Adesto.

One thought on “A Self-Sufficient Serial Flash Memory”

Leave a Reply

featured blogs
Nov 5, 2024
Learn about Works With Virtual, the premiere IoT developer event. Specifically for IoT developers, Silicon Labs will help you to accelerate IoT development. ...
Nov 1, 2024
Self-forming mesh networking capability is a fundamental requirement for the Firefly project, but Arduino drivers don't exist (sad face)...

featured chalk talk

Shift Left Block/Chip Design with Calibre
In this episode of Chalk Talk, Amelia Dalton and David Abercrombie from Siemens EDA explore the multitude of benefits that shifting left with Calibre can bring to chip and block design. They investigate how Calibre can impact DRC verification, early design error debug, and optimize the configuration and management of multiple jobs for run time improvement.
Jun 18, 2024
33,999 views