nRF51 Architecture

Leave this field empty if you're human:

nRF51 Architecture Overview

At the heart of the nRF51 architecture are the 32-bit industry standard ARM Cortex-M0 processor and the 2.4GHz Multi-protocol radio transceiver which supports a range of protocols including Bluetooth low energy, ANT, and proprietary 2.4GHz RF protocols. The popular low-power cost-effective ARM Cortex-M0 CPU has a relatively fast start-up time (around 2.5us) and a fast duty cycling which leads to a boosted Bluetooth device responsiveness. In addition to that, Flash/RAM memories are embedded in the same chip die. The nRF51 SoC has also a good set of hardware peripherals as we will see in the next section. The nRF51 SoCs offer a great value for money, the cost of these SoCs on wholesale is in the range of 2$ per chip ( 2020 ). As can be seen in the block diagrams below and throughout this lesson, you are getting a lot for that money.  This architecture has been around since 2012 and its quite mature and had without a doubt a great success in the BLE market. The widely popular educational kit BBC Micro Bit is based on the nRF51. Nevertheless, due to the rapid growth of the BLE specifications in the past few years, the nRF51 is only recommended when cost is the main constraint in your BLE-enabled project, and support/qualification for Bluetooth 5 features is not needed.

System Blocks & Peripherals

There are abundant of hardware resources in the nRF51 architecture. These hardware resources are the core of the nRF5x family and they are also found in the nRF52 series with some additions and enhancements (For instance, The RADIO peripheral on the nRF52 series has support for Bluetooth 5 features).

Most of these hardware resources are common in all modern microcontrollers’ architectures( Ex: TIMER , ADC , etc..); while some other resources are unique to the nRF5x family and are there to facilitate and support ultra-low power operation (EX: PPI, GPIOTE, etc..), lastly, few of these hardware components are meant to accelerate common repetitive operations defined by the Bluetooth low energy protocol (aka: SIG BLE specifications) and hence serve as a power/performance optimization features(Ex: CCM, AAR, etc..).

For the sake of simplification, we can logically classify these hardware resources into three logical groups: interface peripherals, cryptographic hardware accelerators, and system peripherals (system blocks). The following paragraphs provide a summary for these hardware resources.

Interface Peripherals: The main purpose of these hardware resources is to enable the SoC to interface with external devices such as another BLE device, sensors, and interfaces in general:

• 2.4 GHz Radio (RADIO): This is the core peripheral responsible for the SoC wireless connectivity, and probably one of the main reasons why you are considering the nRF5x SoC in the first place. The RADIO contains a 2.4 GHz radio transmitter/receiver that is capable of supporting a number of short-range wireless protocols. Keep in mind that there is no Blutooth5 hardware support on the nRF51 RADIO peripheral. We will put this peripheral under the microscope in the Intermediate Level of this course.
• General-Purpose Input/Output (GPIO): One GPIO peripheral with up to 32 individual pins that can be configured with pull-up or pull-down resistors for input and with different drive capacity for output. Very fixable block to interact with external hardware components. GPIO hardware, and available hardware abstraction layer in the nRF5 SDK is studied in Lesson7.
• GPIO tasks and events (GPIOTE): The GPIO Tasks and Events (GPIOTE) block provides functionality to internal components in the SoC to access GPIO pins using tasks and events (Without the CPU intervention), which is a great power/performance feature as we will see in following lessons. Hands-on exercises on the GPIOTE are covered in great depth in  Lesson10.
• Serial Peripheral Interface (SPIM) Master :  An interface bus widely used to transfer data to/from external chips, sensors, and SD cards. It supports multiple slaves. (No Quad or High-Speed SPI support on the nRF51).
• Serial Peripheral Interface (SPIS) Slave : The slave implementation of the SPI.
• Two Wire Interface (TWI)- I2C compatible:  A very popular multi-master, multi-slave interface protocol intended to allow multiple slave chips to communicate with one or more master chips. Used widely to interface with sensors and actuators.
• Universal Asynchronous Receiver/Transmitter (UART):  A very popular peer-to-peer interface for external components and sensors. The UART implements support for the following features: Full-duplex operation, Automatic flow control, Parity checking and generation for the 9th data. We will cover this peripheral and available hardware abstraction layers, drivers and libraries (serial library) in-depth in Lesson11.
• Quadrature Decoder (QDEC): The Quadrature Decoder (QDEC) can be used for decoding the output of an off-chip quadrature encoder. Popular use of this peripheral is to support the scroll feature of a wireless computer mouse.
• Analog to Digital Converter (ADC): 10-bit incremental Analog to Digital Converter with 8 channels sampling.
• Low Power Comparator (LPCOMP): It compares an input voltage against a reference voltage. This comparator is frequently used as an analog wakeup source from System OFF or System ON sleep modes.

Cryptographic hardware accelerators(cryptographic co-processors): Dedicated hardware to accelerate common security operations defined by the Bluetooth low energy protocol (SIG BLE specifications) for pairing(cryptographic keys generation, cryptographic keys exchange, and encryption of the connection), bonding(optional storage of permanent cryptographic keys), and anti-tracking(privacy). Having dedicated hardware for common operations does free the CPU from repetitive tasks which is a great power/performance feature.

• Random Number Generator (RNG): The Random Number Generator (RNG) generates true non-deterministic random numbers based on internal thermal noise. Used in the security layer of communication stacks. The ability of generating true random numbers is a core requirement for all FIPS compliant cryptographic algorithms. Random numbers are also used in many situations by the BLE protocol stack as a mechanism to reduce the possibility of BLE packets collisions.
• AES CCM Mode Encryption (CCM): The AES CCM (Counter with CBC-MAC) is the cipher algorithm of choice for encryption by the BLE specifications. The BLE specifications define a mechanism to optionally encrypt BLE packets at the link layer. Therefore, when security is enabled, this system block is used intensively by the security layer of the BLE stack(SoftDevice) to do the encryption instead of relying on the CPU to implement the computational-hungry AES CCM algorithm, this again frees the CPU from highly repetitive and time-consuming tasks.
• AES Electronic Codebook mode encryption (ECB): AES ECB is a single AES block encrypt hardware module. It supports 128-bit AES encryption. It can be used for a range of cryptographic functions used to implement application-level security.
• Accelerated Address Resolver (AAR): This hardware implements a cryptographic operation defined by Bluetooth low energy protocol (SIG BLE specifications) related to anti-tracking(privacy).

System Peripherals (System blocks): hardware resources used mainly internally by the SoC and has a core functionality for the SoC:

• Power management (POWER): A sophisticated unit that has high granularity control over the power distrusted to almost all internal components. It also includes a set of internal(Inside the nRF5x SoC) linear Low Dropout regulator(s) ( aka: LDO ) and switching regulator(s) (aka: DC/DC regulators) that are used to regulate the input voltage to the SoC. It takes as an input an unregulated voltage(For instance: a coin cell battery voltage) and tries to make sure that the internal components (CPU, RADIO, etc..) are receiving a regulated stable voltage. This unit also contain circuitry to monitor the input supply source like: a fixed brownout reset detector to hold the system in reset when the voltage is too low for safe operation, and an optional power fail comparator.
  
• Clock management(CLOCK):  Clocks sourcing unit that provides automatic oscillator management. It includes a set of internal(Inside the nRF5x SoC) oscillators to generate the clocks(HFCLK and LFCLK ) needed by the different internal components.
  
• Real Time Counter (RTC):  This system block is used to maintain timing on the system. Do not confuse this system block with Real-time clock which is also abbreviated by RTC. The RTC on an nRF5x SoC is a 24 bit low-frequency counter with frequency prescaling, tick, compare, and overflow events support. Think about it as a low-resolution, low-power timer.  This system block is used intensively in the Intermediate Level of this course in conjunction with the SoftDevice. In addition, for using it with the SoftDevice, the RTC is used by many other libraries and modules this is why we have several RTC hardware on chip. The RTC uses very little power while running, and is therefore used to supervise sleep duration and to wake the CPU after a certain amount of time. It’s worth noting that this system block operate on the low power LFCLK clock source and hence the low power.
• Watchdog timer (WDT): Very useful block to detect and recover from various system failures. The watchdog is implemented as a down-counter that generates a TIMEOUT event when it wraps over after counting down to 0. This system block also uses the low-frequency clock source (LFCLK).
• Timer/counter (TIMER): The TIMER block is frequently used and is very handy in many situations where precise hardware timing is required(It provides way better resolution than the Real Time Counter). It can operate in two modes, Timer mode and Counter mode. This block uses the HFCLK and hence not quite power friendly. We will dive into its hardware and available hardware abstraction layers, drivers in Lesson8.
• Programmable Peripheral Interconnect (PPI): The Programmable Peripheral Interconnect (PPI) is a core system block which enables different peripherals to interact autonomously with each other using tasks and events and without having to use the CPU ( For performance/power optimization). Covered in details in Lesson9 with hands-in exercise.
• Temperature sensor (TEMP): The temperature sensor is an on-chip sensor that measures the silicon die temperature. Range -25C to +75C with resolution of 0.25 degree. The TEMP is experimented with the UART in Lesson12 to send the temperature of the die to a host computer through UART.
• Serial Wire Debug Port Interface(SW-DP): Standard interface for programming and debugging ARM Cortex Processors.
• Non-Volatile Memory Controller (NVMC): Used for writing and erasing of the internal flash memory(CODE) and the non-volatile registers UICR (User Information Configuration Registers).

Clock Resources

The nRF51 series chips can source the system clocks(HFCLK and LFCLK) from a range of internal or external high and low frequency oscillators and distribute them internally to peripherals and system blocks based upon a module’s individual requirements. This prevents large clock trees from being active and drawing power when system blocks/peripherals needing this clock reference are not active. If a firmware enables a module(system block/peripheral) that needs a clock reference without the corresponding oscillator running, the clock management system inside an nRF51 SoC will automatically enable the required oscillator and provide the clock. When the system block/peripheral goes back to idle, the clock management will automatically set the oscillator to idle, which saves power(Default mode). To avoid delays involved in starting a given oscillator, the firmware can override the automatic oscillator management so it keeps oscillators active when no system modules require the clock reference (This feature is called Low Latency and is discussed with depth  in Lesson 14 ).

HFCLK stands for High Frequency Clock, this is the main clock on the SoC; while the LFCLK stands for Low Frequency Clock. The idea here is to try to switch off the power-hungry HFCLK source when the device goes to sleep, and keep the low-power LFCLK source on to wake up the SoC at the right time interval.

The HFCLK source is needed by the CPU, RADIO, and almost all units in the system except the RTC and WDT. The RTC and WDT operate on a low power, low frequency clock which is the LFCLK. The RTC uses very little power while running, and is therefore used to supervise sleep duration and to wake the CPU after a certain amount of time. The RTC is used intensively by the SoftDevice to maintain protocol timing defined by the Bluetooth Low Energy protocol (Covered in-depth in the intermediate level course).

For HFCLK, you always need an external 16Mhz crystal along with two loading capacitors to be connected across XC1 and XC2 pins(See example below) when using the SoC for BLE. These two pins are fixed function pins, they can not be configured as GPIO.

However, for the LFCLK, you have the choice to use an external 32.768KHz crystal along with two loading capacitors to be connected across XL1 and XL2 pins. These two pins are multiplexed and can be configured as GPIO. This configuration will yield a very accurate and power efficient design, but on the expense of:

• Losing two GPIO pins for clock management.
• PCB space usage for the relatively chunky 32.768KHz crystal and the two loading capacitors.
• Bill of materials(BOM) cost increase for the 32.768KHz crystal and the two loading capacitors.

Having an external 32.768KHz crystal makes the LFCLK generation independent of the HFCLK, and hence facilitates switching off the HFCLK completely when in sleep.  Use an external 32.768KHz crystal to generate the LFCLK when low power consumption is a main design constraint.

The other common option you have for the LFCLK is to use the internal 32.768KHz RC oscillator. This configuration will save on cost, PCB space, and the two GPIOs, but it is inefficient in both oscillator accuracy and power consumption terms. The internal 32.768KHz RC oscillator accuracy is +/-500 ppm. It must be compensated by constant time-consuming calibration, as +/-500 ppm does not meet the Bluetooth Low Energy protocol specifications. Power wise, the internal RC oscillator relies on the HFCLK clock to generate the 32.768KHz clock, therefore, the HFCLK clock system will be kept on all the time(even when the SoC goes to sleep) which has high negative impact on power consumption.

Use the internal 32.768KHz RC oscillator to generate the LFCLK when low power consumption is NOT a main design constraint and you are trying to save on cost, GPIO pins and/or PCB space(size-constrained designs).

Example: The nRF51-DK Development Kit, which hosts the nRF51422 SoC, has two external crystals. The master one is the 16MHz which is the one directly connected to the SoC and used to generate the HFCLK clock needed by the CPU, RADIO, and most system blocks and peripherals. The second crystal is the 32.768KHz low frequency, low power crystal that is used to generate the LFCLK clock needed by the RTC and the WDT system blocks.

Notice how the two solder bridges (SB1 and SB2) are shorted by default to connect the 32.768KHz crystal to XL1 and XL2. This shows that the nRF51-DK supports the generation of the LFCLK using an external crystal by default. However, you still have the option to use the internal 32.768KHz RC oscillator and free the two GPIO pins(P0.26 and P0.27) by cutting the solder bridges (SB1 and SB2) and shortening the solder bridges (SB3 and SB4). Therefore, the 32.768KHz external crystal is referred in some context as an optional crystal.

Memory Layout

The memories available inside an nRF51 SoC can be categorized into two types:

Non-volatile memory:

• Code memory. This is a non-volatile flash memory (aka: Code FLASH) where your firmware code, communication stack, and constant data will be stored. It can also be used for storing small data (Ex: logs, BLE bonding information, small sensors readings) that are retained even when the chip loses power. Depending on the variant of the nRF51 SoC , you have 256-128 KB of flash memory.
• Factory Information Configuration Registers (FICR) which is a non-volatile small memory containing read-only chip-specific information and configuration. Example: part code, part variant, hardware version and production configuration. This is a small memory of about 256 Bytes.
• User Information Configuration Registers (UICR) which is also a non-volatile small memory that stores user specific settings(Ex: which pin should be used as a reset pin).  In addition to storing settings, the nice thing about the UICR is that it can be configured by the user to store important application-related non-volatile information(Ex: Location of an optional bootloader, storing unique identifiers for BLE beacons) as we will see in the intermediate level course. This is a small memory of about 256 Bytes.

Volatile memory:

• Random Access Memory (Data RAM). This is the memory used in execution for things like the stack, heap, automatic variable, local buffers. This type of memory is volatile. Note that through the EasyDMA hardware available in some interface peripherals and all cryptographic co-processors, this memory can be accessed without relying on the CPU, which is a great performance/power feature. Depending on the nRF51 SoC number, you have 32-16 KB of RAM memory.
• Peripheral Registers (PER). Memory-mapped registers of the different peripherals and system blocks in the system. These special memory locations enables performing input/output (I/O) between the ARM central processing unit (CPU) and the system blocks and peripheral on the SoC. This type of memory is volatile.

All memory blocks and system blocks/peripherals registers are mapped in a common memory map(address space) as illustrated in the figure below :

The Data RAM (Address 0x2000 0000) is divided into blocks for separate power management schemes which is controlled by the power management system block. Each block is divided into two 4 kByte RAM sections with separate RAM AHB slaves. The power management block can be configured to allow certain blocks of RAM to be retained during different sleep modes, which gives finer control over memory power consumption.

 

Available Chips Options

There are four SoC chips options in the nRF51 series :

Hardware peripherals wise, all these chips have almost the same hardware peripherals with some minor differences, However, when it comes to the supported short-range wireless protocols (Bluetooth low energy, ANT) they differ as follows:

The nRF51822 supports only Bluetooth Low Energy. The nRF51824 is simply the automotive grade of the nRF51822 and also only support Bluetooth Low Energy.

On the other hand, the nRF51422 supports both ANT and Bluetooth Low Energy  wireless protocols.

Finally, the nRF51802 is a low-cost implementation of the nRF51822. The low price comes at the expense of a higher current consumption and weaker radio reception compared to the nRF51822.

Again, the nRF51 series does not support Bluetooth 5.

Full comparison of the nRF51 SoCs is shown below:

All documentation related to the nRF51 SoCs, such as Production Specifications(equivalent to IC datasheet), Product Change Notification (PCNs), Informational Notice (INs), and Product Anomaly Notification(PANs) are available for each SoC in the nRF51 series on Nordic Semiconductor infocenter.

Common hardware and software architecture among the different chips and consistent peripheral addressing making these chips easy to work with as we will see in the Lesson 6 – The Unified Peripheral Architecture . It is also worth noting that the core registers and registers for tasks, events, shorts and interrupts have equal offsets for all peripherals.

Advanced features in the nRF51 architecture

The features listed below are actually present across all nRF5x family (Both nRF51 and nRF52) and they facilitate the ultra-low-power capabilities on the nRF5x family, as we will see in the next lessons and tutorials.

1. PPI ( Programmable Peripheral Interconnect ):  A network of buses and switches that allow different peripherals/system blocks to interact with each other independent of the CPU . This saves power by minimizing processor active time and at the same time relaxes real time requirements for the processor. See illustrations below:

 

2. Flexible GPIO:  It allows the digital interfaces of the peripherals to be mapped to most pins available on the SoC. This feature is achieved using an embedded pin crossbar. This has a huge advantage in reducing the complexity of the PCB(Ex: Reduce the number of required PCB layers) of the device or the development board. See illustration below:

 

3. Automated power management: This is a quite sophisticated unit and one of the main factors why an nRF5x SoC can be powered by a coin-cell battery for up to years. The purpose of this unit is to minimize active modules(peripherals, system blocks, cryptographic co-processors) and minimize peak and average current. With automated power management, peripherals only use power when they need power.

There are two explicit sleep modes that a developer can put the nRF5x SoC into. They are called System On and System Off.

In System On sleep mode, which is the one commonly used, the CPU can be put explicitly to sleep ( through user-friendly APIs provided by the nRF5 SDK Power Management Library , which internally uses the ARM assembly instructions of SEV,  and WFE  )  as we will see in-depth in Lesson14. In System On the needed peripherals can still be interacting with each other and the memory using the PPI and EasyDMA respectively (Covered next). In System On mode, the CPU can be woken up using interrupts or events that are configured to trigger interrupts. At the same time, the automated power management unit is actively maintaining the usage of power of the system blocks and peripherals. In System On, the expected current consumption of the SoC is in the order of few micro amperes.

The other sleep mode is System Off, this is the deepest power saving mode the SoC can enter. In this mode, the CPU, system’s core functionality, system blocks, and peripherals are powered down and all ongoing tasks are terminated. In this mode, the CPU can only wake up on GPIO DETECT signal , or LPCOMP ANADETECT (voltage input crossing a certain value). The system always resets after waken up from a System Off sleep mode. In System Off, the expected current consumption of the SoC is in the order of  sub-micro amperes( several hundreds of nano amperes).

Power management on the nRF5 SoC is the focus of Lesson14.

4. EasyDMA (Built-in DMA inside the peripherals ): The EasyDMA significantly eliminate CPU involvement in frequent data transfer operations, which saves power by minimizing CPU active time, and at the same time relaxes real time requirements for the CPU. The acronym EasyDMA stands for Easy Direct Memory Access. Direct Memory Access is a common hardware in most CPU architectures, however, the Easy here stands for a DMA which is built-in the peripheral itself and not as a DMA hardware which is shared among all system blocks and peripherals. Example the RADIO peripheral has an EasyDMA which is inside it (and not shared with any other peripheral), which allows the RADIO to read/write to RAM without the CPU involvement. Note that there are other peripherals on the nRF51 that has built-in DMA (EasyDMA): Serial Peripheral Interface(SPI) ,and all cryptographic co-processors. This feature was taking to the extreme in the nRF52 and was added inside even more peripherals and system blocks.

In other words, while the PPI feature allows peripherals to interact to each other autonomously, the EasyDMA allows the peripherals to interact with memory (RAM) autonomously. One of the main strategics followed by Nordic Semiconductor to reduce power consumption is to offload processing from the CPU and put it into sleep as much as possible. Both the PPI and EasyDMA can help in that significantly as we will see in the next lessons.

nRF51 Development Boards

Listed below are the official nRF51 development boards By Nordic Semiconductor.

nRF51-DK (nRF51422) : This is the recommended development kit(DK) to be used in the initial development phase, and prototyping of your nRF51-based project. About 2/3 of the size of this board is consumed by the connectors and the interface MCU circuitry. The interface MCU provides a programmer/debugger to the nRF51 SoC, a user-friendly virtual COM port interface(UART-USB Convertor), and a simple drag and drop Mass Storage Device (MSD) programming interface. The nRF51 DK is a single-board development board that has the following key features:

• Hosts the nRF51422 SoC.
• All GPIO and interfaces available at edge connectors.
• Buttons and LEDs for basic user interaction.
• I/O interface for Arduino form factor plug-in modules(Arduino Shields).
• Connector for RF measurements.
• Pins for power consumption measurements.
• SEGGER J-Link OB Debugger with Debug out functionality. This enables you to use the nRF51-DK as a programmer/debugger to other nRF5x-based boards with the appropriate connectors.
• Virtual COM port interface (UART-USB Convertor) provided by the interface MCU.
• Drag and drop Mass Storage Device (MSD) programming provided by the interface MCU.
• mbedOS enabled (We will talk about this in Lesson4).
• Accepts power through:
  • USB.
  • External source (1.8V-3.6V).
  • Single 2032 coin-cell battery, onboard battery holder(On the backside of the board).

The board ID of the nRF51-DK is PCA10028 .

nRF51-Dongle (nRF51422) : This is a USB stick form factor development board, commonly used as a BLE sniffer and for debugging/testing BLE applications with the nRF Connect for Desktop. Key features of this dongle:

• Hosts the nRF51422 SoC.
• RGB LED.
• 6 solder pads for GPIO/interface connections.
• Supports nRFSniffer – Bluetooth Smart protocol sniffing firmware.
• Supports Master Emulator – Bluetooth Smart Peer connection firmware(For use with nRF Connect for Desktop).
• USB drag and drop programming and USB Virtual COM port for serial terminal provided by the interface MCU present on the back of the dongle.
• mbedOS enabled(We will talk about this in Lesson4).
• Accepts power through:
  • USB.
  • External source (3.6V-5.5V) regulated through an onboard voltage regulator.

The Board ID for the nRF51-Dongle is PCA10031

Enroll to the to the Nordic nRF5x BLE In-Depth Training Course (Foundation Level) to access full materials.

References and pictures:
Nordic Semiconductor www.nordicsemi.com
ARM Mbed https://os.mbed.com/