Get to know the differences between memory options and the trade-offs you need to make when working with Bluetooth development projects.
The IoT applications of today are becoming ever more complex. That complexity increases the demand for memory capacity. High-end Bluetooth SoC makers typically opt for a combination of RAM and flash memory.In addition to an efficient microprocessor, a Bluetooth Low Energy 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, which 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 is able to retain its content for years with no power source. In a Bluetooth Low Energy 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 not being able to update the product after release is a major drawback.
How much memory?
The amount required depends on the end application. A complex wearable could require the full 256kB RAM and 1MB Flash offered by the Nordic nRF52840 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 of performance versus cost. The more memory that is required, the more costly the device will be to manufacture.
While a Bluetooth Low Energy SoC can in some cases reduce the RAM requirement, it very much depends upon the application and the amount 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.
Read more: Firmware updates for smart technologies
Of course, running "live" firmware upgrades requires extra memory. Specifically, the chip requires sufficient flash memory to simultaneously hold the old firmware, while buffering the new. 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 that is 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 the choice of microprocessor and also the memory configuration. Today, the Nordic nRF52 Series SoCs embed up to 1MB Flash and 256 kB RAM so separate memory chips are not 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 need to be updated. This cuts the duration of the OTA update and reduces the risk of corruption.