New features in nRF52

Check the infocenter explanation

There are lots of improvements in nRF52 compared to nRF51. Features that are the same in both products are not mentioned here, only changes worth mentioning will be described. It is expected that you have prior knowledge of nRF51 so that you are able to judge the improvements.

  1. CPU ===

nRF52 has an ARM Cortex-M4F processor which is very powerful as compared to ARM Cortex-M0 on nRF51. For simplicity we will use M4F and M0 from now on when be talk about just the CPU alone inside the product.

Both of them are 32-bit microprocessors but M4F has a higher performance per clock design, powerful digital signal processing (DSP) instruction set, and floating point capability. All of these mentioned features will provide the computing performance needed for the broader wearable and IoT industry.

The DSP and single-precision floating point capability of the M4F further increases its desirability for use in wearable and IoT devices. The ability to perform single-instruction multiple-data (SIMD) operations, single-cycle multiply accumulate (MAC) instructions, and floating point operations using (FPU) without calling complicated subroutines enables efficient processing and control of digital signals from the many sensors used in these systems.

What does "higher performance of M4F per clock design" mean?

M4F in nRF52 runs at 64MHz as compared to M0 in nRF51 which runs at 16MHz. Clocking CPU with higher speed means applications are able to finish their tasks faster, but it also means higher consumption of power per second. So it is very important to compare CPU's per MHz performance.

Take a look at CoreMark and Dhrystone per MHz performance benchmark below image description

This shows that M4F is 45.9% ((3.40-2.33)/2.33) faster at executing instructions per second than the M0 (2.33 CoreMark/MHz).This means that if they are running at the same clock frequency the same task can be done 46% faster in M4F and allows the device to quickly go back to a lower power sleep state. In embedded systems that is a lot of power saving, because your battery that lasted for a year for your product might now last for a year and half just by changing CPU from M0 to M4F and keeping everything else exactly same (including CPU clock speed).

  1. Power ===== @Stian has made a nice tutorial for measuring current for nRF52832 Engineering B and S132 v2.0.0-7.alpha and Measuring current with PCA10040 v0.9.0

  2. Memory ====== 3.1 Flash (Code Memory/ROM/Non Volatile Memory)


nRF52 can have as much as 512KB of Flash as compared to maximum of 256KB on nRF51. The page size is also increased to 4KB from 1KB. This is an important thing to note and because of this increase, the flash operation per page will take longer time.

On the nRF52, the NVMC (Non Volatile Memory Controller) is used for configuring and controlling flash, FICR, UICR and Instruction cache (I-Cache 2048 bytes).

In UICR, CLENR0 is removed as you use MWU to partition memory into regions. RBPCONF has been replaced by APPROTECT (more on this later).

Even though I-Cache is a different memory technology, it is controlled and configured by NVMC as this cache is only used for code residing in flash.

Quote from product specification:

Cache will use some current when enabled. If the reduction in average current due to reduced flash accesses is larger than the cache power requirement, the average current to execute the program code will reduce. When disabled, the cache does not use current and does not retain its content.

3.2 RAM(Volatile Memory)

nRF51 supports a maximum of 8 RAM AHB slaves with 4KB of RAM section connected to each slave. So the maximum RAM size a product could have is 8 * 4 = 32KB.

nRF52 support a maximum of 8 RAM AHB slaves with two sections of 4KB RAM connected to each slave. So the maximum RAM size a product can have is 8 * 2 * 4 = 64KB.

To know how much RAM is implemented on your chip, you need to read product specification for your chip revision.

RAM contents are lost when the system loses power, but the contents can be retained in System OFF mode and this is configurable in POWER.RAM[n] register for each available RAM slave.

  1. Memory Protection ============== nRF52 has a new module called Memory Watch Unit(MWU) which is able to listen and detect read, writes or both to four configurable and two fixed memory address regions. It is worth mentioning that MWU fires a configured interrupt ONLY AFTER the memory access already happened. That is, it will not stop or trap the access but only let the firmware know that protected block has been accessed. Cortex-M4 has multiple AHB bus connects and it will not be possible to listen and trap all memory accesses that could happen in the same cycle. MWU will not generate hardfaults, only (configurable NMI) interrupts if enabled. If you want to know exactly which peripheral was accessed, then you can read PERREGION[0 or 1].SUBSTATWA and PERREGION[0 or 1].SUBSTATRA. Each bit then would correspond to its respective Peripheral ID

ARM-Cortex M4F has an MPU in itself. Documentation and software support for ARM MPU is not part of Nordic releases.

Also the readback protection on nRF51 (configured through RBPCONF in UICR) is replaced with APPROTECT. The difference is, with APPROTECT you either block ALL or NONE of the CPU registers and memory mapped addresses (APPROTECT.PALL). This means that if APPROTECT.PALL is set, then debugger is blocked to access any (CPU and peripheral) registers. This is done to add extra layer of security for those who want to protect their firmware IP.

The new BPROT module in nRF52 can be configured to protect flash memory block each of size 4KB against any write and/or erase operations. CPU will hardfault in case any attempt is made to erase/write protected blocks. It is worth noting that the settings in this module are cleared at system reset, so it is up to the firmware to configure this module at early stage of system boot up.

  1. CLOCK ========= Clock architecture has changed a lot on nRF52. 5.1 HFCLK

Instead of internal RC oscillators, nRF52 is based on PLL to provide better accuracy and stable system wide clock.

By default, the PLL will start in open loop mode with 32MHz clock output until the externtal crystal (only 32MHz XTAL is supported) is started and stable. The PLL will then gradually change frequency to match that of the XO and generate a CLOCKREADY event when PLL is locked and starts to operate in closed loop mode. This means that the clock will always be provided by PLL (either in open loop mode or locked to external crystal oscillator). In addition to the HF clock output clock frequencies available on nRF51, HF clock controller on nRF52 provides 64MHz CPU clock and 32MHz peripheral clock.

5.2 LFCLK

This is same as in nRF51 including calibration mechanism.

  1. GPIO ======= Same as in nRF51 except for Latch and DetectMode

Quote from spec

When a pin's PINx.DETECT signal goes high, a flag will be set in the LATCH register, e.g. when the PIN0.DETECT signal goes high, bit 0 in the LATCH register will be set to '1'.The LATCH register will only be cleared if the CPU explicitly clears it by writing a '1' to the bit that shall be cleared, i.e. the LATCH register will not be affected by a PINx.DETECT signal being set low.

The LDETECT signal will be set high when one or more bits in the LATCH register are '1'. The LDETECT signal will be set low when all bits in the LATCH register are successfully cleared to '0'.

  1. GPIOTE ========= nRF52 has 8 GPIOTE channels compared to 4 GPIOTE channels in nRF51.

  2. PPI ====== nRF52 has four additional usable channels (16,17,18 and 19), two additional channel groups (CHG[4] and CHG[5]), and an additional FORK mechanism.

Quote from spec

Each TEP implements a fork mechanism that enables a second task to be triggered at the same time as the task specified in the TEP is triggered. This second task is configured in the task end point register in the FORK registers groups, e.g. FORK.TEP[0] is associated with PPI channel CH[0].

This means that event connected to CH[n].EEP will result in two tasks (CH[n]TEP and FORK[n].TEP). The fork mechanism is enabled by default and is not configurable. It will not have any power consumption penalties if FORK features is not used because this is just a copy of CH[n].TEP.

  1. RADIO ======== Even though the programmable interface to the RADIO is maintained to be the same, there are a lot of internal improvements and few new features which are listed below.
  • Better internal performance and transceiver sensitivity.(+4dB link budget from nRF51). The advantage of this is that you get improved range.
  • RF interface is now single ended with on-chip Balun (differential, off-chip balun on nRF51). The advantage of this is that the RF calibration with on-chip balun is done in the production line and the chip can be used directly without the need of any external balun.
  • About 44% reduced RX current when using DC/DC and 10% reduced RX current with LDO.
  • About 34% reduced TX current when using DC/DC and 9% increased TX current with LDO. image description
  • 3x faster ramp up times for RX and TX. 130us in nRF51 and 40us in nRF52. Ramp up time is the time between the TASKS_TX/TASKS_RX started and receiving EVENTS_READY. This means that the application will have about 90us extra time for processing for each RADIO ramp up cycle.
  • 6x faster switching time (switching from RX->TX or from TX->RX). 130us in nRF51 and 20us in nRF52. This means that every connection interval will save 90us switching time which could be available for application processing.
  • On nRF51, TX mode was limited to a maximum of 16ms which was dependent on crystal accuracy. On nRF52 TX mode can be used continuously without any limitations or need to switch it off.
  • Only 32MHz crystal is supported as compared to 16/32MHz support on nRF51. This is done to make the design simpler and more efficient.
  1. TIMERS ========== Two additional timers and 6 CC (CaptureCompare) registers for TIMER3 and TIMER4 in nRF52.

image description

Using prescaler, you can use 16MHz or lower frequency for TIMER ticks.

  1. RTC ======= One additional RTC available on nRF52

image description

Using prescaler, you can use 32KHz or lower frequency for RTC ticks.

  1. Serial Communication (TWI, UART and SPI) ============================== image description

This image is giving a lot of information but I have learned that it is confusing for some. So I will try to explain what it is. There are four serial instances on nRF52, which have their own register address space. It is only possible to have one module using an instance at a given time. For example, SPIM and SPIS cannot use the instance SERIAL0 simultaneously.

  • Instance UART with register base address 0x40002000 can only be UARTE and can be used for nothing else. Legacy UART module from nRF51 is still available to maintain backward compatibility but we do not recommend new designs to use it.
  • Instance Serial0 with register base address 0x40003000 can either be used as SPIM, SPIS, TWIM or TWIS. It also says that traditional SPI and TWI from nRF51 are available to maintain backward compatibility but we do not recommend new designs to use it.
  • Instance Serial1 with register base address 0x40004000 can either be used as SPIM, SPIS, TWIM or TWIS. It also says that traditional SPI and TWI from nRF51 are available to maintain backward compatibility but we do not recommend new designs to use it.
  • Instance Serial2 with register base address 0x40023000 can either be used as SPIM or SPIS. It also says that traditional SPI from nRF51 is available to maintain backward compatibility but we do not recommend new designs to use it.

Examples:

  • UARTE+SPIM0+TWIM0 (Not OK, SPIM and TWIM cannot use same Serial0 instance)
  • SPIM0+TWI2 (Not OK, there is no TWI support for Serial2 instance)
  • UARTE+SPIM0+TWIS1+SPIM2 (OK)
  1. Peripheral specific EasyDMA =========================== EasyDMA is not traditional DMA, it is light weighted and tuned to suit each peripheral. Which means that easydma of one peripheral could differ in behavior compared to easydma of another peripheral (SPIM EasyDMA will differ slightly compared to TWIM EasyDMA).

Below are some of the common things between them

  • They only operate on Data RAM and will not work for flash. Pointing EasyDMA to anything else than Data RAM might result in hardfault or RAM corruption.
  • They operate only in full byte mode. Take a look at one good post regarding this.
  1. NFCT (Near Field Communication Tag) ============================== TBD

  2. EGU (Event Generation Unit) ========== TBD

  3. PWM (Pulse Width Modulation) ============ On nRF51, it was possible to generate PWM using TIMER+GPIOTE+PPI. But the setup has large software overhead and there were issues when trying to update the duty cycle of the PWM output. Our engineers took all those issues into account and desgined a dedicated PWM module on nRF52. There are three PWM modules each with 4 channels can provide upto 12 PWM outputs to be driven on selected GPIOs.

The documentation given is very detailed. To help you understand the examples given in the documentation, I will create a different blog to explain them in detail (when i find some time) and link it here.

  1. PDM (Pulse Density Modulation) ============ TBD