The IoT applications of today are becoming ever more complex. That complexity increases the demand for memory capacity. High-end Bluetooth LE SoC makers typically opt for a combination of RAM and flash memory.

In addition to an efficient microprocessor, a Bluetooth LE SoC demands enough RAM and flash memory to support an RF stack and application software. Crucially, the device also needs enough memory to perform over-the-air (OTA) firmware updates if a product is to be competitive in today’s thriving IoT market.

Let’s take a look at what kinds of memory you need, and why.

Which memory type? RAM v Flash v ROM

Random Access Memory (RAM) is the working memory used by the processor. Information can be quickly written to and read from RAM, enables the processor to work at such high speeds. The major downside of RAM is its volatility. Storage is temporary, so the information is lost when the power is cut.

Flash memory can retain its content for years with no power source. In a Bluetooth LE SoC, the RF protocol stack is stored together with the application software in flash memory. Information can be read and written thousands of times during the product’s life. However, flash memory costs more and will consume more power than other types of memory.

Some manufacturers produce chips with Read-Only Memory (ROM). While this is both less expensive and less power-hungry than flash, the content is fixed forever and cannot be updated after manufacture. This may suit some simple devices, but lacking the option to update the product after release is a significant drawback.

How much memory?

The amount required depends on the end application. A complex wearable could require the full 512KB RAM and 1MB flash offered by the Nordic nRF5340 SoC. A relatively simple beacon may only need the 24 kB RAM and 192 kB flash of the Nordic nRF52810 SoC.

Of course, it also comes down to a trade-off between performance and cost. The more memory that is required, the more costly the device will be to manufacture.

While a Bluetooth LE SoC can reduce the RAM requirement in some cases, it greatly depends on the application and the number of connections configured. If your application creates complex data structures while working, that will also increase the RAM required.

Sufficient flash is needed to hold the stack and application software during code execution and when the power is turned off. For a complex application with many features, the flash requirement can easily reach several hundred kilobytes.

Estimating the flash requirement

That said, figuring out how much flash you need is more complex than just looking at the size of the application code and stack, even when adding in some contingency.

That’s because a key benefit of flash is the ability to upgrade the software via the chip’s wireless link, something that’s not possible with ROM-based devices. Such functionality can be used to upgrade the stack to an enhanced version, fix bugs in the application code, or apply a security patch.

Of course, running "live" firmware upgrades requires extra memory. Specifically, the chip requires sufficient flash memory to hold the old firmware, while buffering the new simultaneously. Once the new code is verified, the old firmware is deleted and overwritten by the new, thus freeing up flash space for yet another upgrade.

In practice, this means that a developer is likely to need more than double the flash capacity required for the application code and stack alone.

Reducing the risk of firmware updates

Previously, designers leaned towards a two-chip approach because it offered flexibility in microprocessor choice and memory configuration. Today, the dual-core nRF5340 Series SoC embeds in a single die 1MB flash and 512 KB RAM to the application processor, in addition to 256 KB flash & 64 KB RAM to the network processor, so separate memory chips are no longer required.

Nordic’s unique software architecture separates the stack from the application code. This gives a clear advantage over the competition when performing OTA firmware updates. Only the stack or application software needs to be updated. This cuts the duration of the OTA update and reduces the risk of corruption.