Without an embedded device such as the 64-MHz, 32-bit ARM M4F processor found in Nordic’s nRF52832 and nRF52840 Systems-on-Chip (SoCs), a single-chip Bluetooth Low Energy (Bluetooth LE) solution would struggle to cope with today’s complex applications such as high-end wearables.
To get the most out of a powerful Bluetooth LE SoC, the processor requires sufficient memory. In an architecture pioneered by the Nordic nRF51 Series in 2012, high-end Bluetooth SoC makers typically opt for a combination of RAM and Flash.
RAM (Random Access Memory) is the processor’s “working memory”. Information can be quickly written to and read from this memory allowing the processor to go about its business at high speed. But RAM is volatile; when the power is switched off, the information is lost.
In contrast, Flash is non-volatile, retaining its content for years even when there is no power. In a Bluetooth LE SoC, Flash stores the RF protocol software (or ‘stack’) (Nordic calls its stacks “SoftDevices”) together with the application software required to optimize the performance of the end product. Another big advantage of Flash is that information can be repeatedly written to, and read from, the memory thousands of times during a product’s life.
The downsides of Flash are its cost and slightly higher power consumption than other types of memory. Some manufacturers produce chips with ROM (Read Only Memory); this is both less expensive and less power hungry than Flash. But the big disadvantage is that ROM contents are fixed forever once the chip has been manufactured.
Memory capacity
RAM and Flash add to the cost of the Bluetooth LE SoC. The amount required depends on the end application. A high-end wearable, for example, could need the full 256kB RAM and 1MB Flash offered by Nordic’s flagship device, the nRF52840 SoC. In contrast, a simple beacon product could easily get by with the 24 kB RAM and 192 kB Flash of the nRF52810 SoC. (One cool feature of Nordic’s nRF51 and nRF52 Series is that a developer can start working with one chip and if the application proves to need a different amount of memory the developer can swap to another chip in the family without having to write new code or invest in new development tools.
A Bluetooth LE SoC will require much less RAM than Flash because the former is used only to store the limited amount of data and variables that are needed immediately (or at least very soon) by the processor to feed the computations demanded by the stack or application. There is no need for the RAM to retain the actual stack- or application-programs. In contrast, 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 and a stack such as Nordic’s S140 SoftDevice (a fully-compatible, multirole Bluetooth 5/Bluetooth LE stack) the Flash requirement can measure up to several hundred kilobytes.
Estimating the Flash requirement for a given application is more involved than just measuring the stack and application code size, adding some contingency, and choosing the appropriate chip. That’s because a key feature of Flash-based Bluetooth LE SoCs is the ability to upgrade the software via the chip’s wireless link. (This is something that’s not possible with ROM-based devices.) Upgrades are useful, for example, to replace the stack with an enhanced version, to fix a bug in the application code, or to apply a security patch.
To perform upgrades, the chip requires sufficient Flash for the new software while using the previous software to run the link and verify new code. Once the code is verified the previous software can be deleted to free up Flash for the next upload. Consequently, a developer is likely to need more than double the Flash capacity than that used for stack and application code alone.
Nordic’s unique software architecture—which cleanly separates the SoftDevice from the application code—offers an advantage over competitors’ solutions when performing Flash-based over-the-air device firmware updates (OTA-DFU). Competitors’ stacks and the application code become inextricably linked when compiled - requiring both to be uploaded when a change is made to either. The nRF51 and nRF52 Series software architecture allows either stack or application software to be uploaded without disturbing the other. That dramatically shortens OTA-DFU duration and reduces the risk of corruption during the upload.