Functional changes

This section lists new and changed features of the Cortex®-M4F processor.

The Cortex-M0 processor in the nRF51 Series has been replaced with Cortex-M4F in the nRF52 Series. The differences between the Cortex-M4F and Cortex-M0 processors are not in the scope of this document and thus not described in detail.

While Cortex-M4F is capable of running code compiled for Cortex-M0, there are some functional differences in the nRF52 Series to pay attention to when porting code from the nRF51 Series. These are described below:

Interrupt event clearing

Clearing an interrupt event may not take effect immediately.

As Cortex-M4F has a write buffer on the system bus, write accesses to peripherals/SRAM may be delayed. In addition, there can be other delays in the bus infrastructure, such as bridges, that may result in writes occurring after the store instruction has been completed.

To make sure the interrupt line is cleared before exiting an ISR, read back the given event register before returning. Any read on the system bus will require the write buffer to be emptied first.

Existing code:
void TIMER0_IRQHandler(void)
{
  NRF_TIMER0->EVENTS_COMPARE[0] = 0;
}
            
Required code:
void TIMER0_IRQHandler(void)
{
  NRF_TIMER0->EVENTS_COMPARE[0] = 0;
  (void)NRF_TIMER0->EVENTS_COMPARE[0];
}
            

Interrupt wakeup time

Waking up from an interrupt takes additional cycles compared to the nRF51 Series. This is due to increased flash startup time and increased startup time for the regulators and oscillators. See tIDLE2CPU in the nRF52 Product Specification for the wakeup time.

If the wakeup time from sleep is important, the interrupt vector table can be moved into RAM. This is done by copying the vector table to a suitable RAM location and pointing to it in Cortex-M4F's Vector Table Offset Register (VTOR). The start of the ISR should also be implemented in RAM to avoid flash latency. The flash will power up in the background when the CPU is running from RAM, so a partial RAM/Flash ISR implementation can improve the interrupt latency without using much RAM.

Important: This feature may not be available if you are using a SoftDevice. Check the SoftDevice Specification.

Unaligned read/write

Cortex-M4F allows unaligned reads/writes, but on Cortex-M0 this leads to a HardFault.

In practice Cortex-M4F splits the read or write into multiple bus accesses. This means that 32-bit and 16-bit reads or writes will not be atomic bus accesses when reading or writing to 32-bit and 16-bit unaligned addresses, respectively. Unaligned accesses are useful to speed up accesses to packed data structures.

Cortex-M4F can generate a UsageFault on unaligned accesses by setting the UNALIGN_TRP bit in the Configuration Control Register (CCR) register. Compilers typically allow you to enable or disable the generation of unaligned memory access instructions.

Interrupt call stack alignment

In Cortex-M4F the default stack alignment is 4 bytes, while in Cortex-M0 it is 8 bytes. The ARM Application Binary Interface (ABI) requires 8-byte alignment, so when executing an interrupt, the stack pointer may not be ABI compliant.

The stack alignment can be forced to be 8 bytes by setting the STKALIGN bit of the Configuration Control Register (CCR).

For more information, see section Handling an exception in the ARM Compiler - Software Development Guide.

Call stack with FPU

Cortex-M4F in the nRF52 Series includes the Floating Point Unit (FPU). Some of the registers introduced by the FPU are preserved on the call stack when executing an interrupts service routine. As more registers are stacked when the FPU is enabled, the interrupt latency and stack size increase.

In order to minimize the stack usage, the Lazy Stacking option can be enabled. This will optimize the call stack usage when the FPU is enabled. More information can be found in the ARM application note Cortex-M4(F) Lazy Stacking and Context Switching.

Code RAM region in the memory map

The memory map for the nRF52 Series introduces a Code RAM region located in Cortex-M4F's Code segment at address 0x00800000. The Code RAM region is a direct mapping of the Data RAM region, which is located in the SRAM segment of Cortex-M4F. This is done because running code from the Code segment is more effective than from the SRAM segment. It is up to the programmer to make sure that the physical program code and RAM sections do not overlap.

System vector table size

Cortex-M4F allows up to 240 interrupts defined by implementation, and 16 predefined interrupts or reserved slots. These 256 potential interrupts each have a 4-byte vector table entry, which means that the total vector table size of Cortex-M4F can be up to 1024 bytes (address 0x400). This size will vary depending on the number of implemented interrupts, but it is good practice to avoid having any static data, such as FW information, before address 0x400.

Additional fault exceptions

In Cortex-M0, there is only one fault interrupt vector (HardFault), while in Cortex-M4F there are three extra fault handlers, MemManage, BusFault, and UsageFault. In addition, these handlers have status registers that provide additional information about what caused the fault. This means that what used to cause a HardFault in the nRF51 Series may cause a different type of exception in the nRF52 Series. For more information about the additional exceptions, see the Cortex™-M4 Devices Generic User Guide.

Flash page size

Flash page size has changed from 1 kB in the nRF51 Series to 4 kB in the nRF52 Series. This has implications when erasing flash content, as you can only delete on a page by page basis. It is recommended to use the FICR CODEPAGESIZE and CODESIZE registers to make portable code.

Protect all mechanism

In the nRF52 Series, the UICR RBPCONF register used for read-back protection has been removed. It has been replaced with the PALL field in UICR's APPROTECT; this can disable all read/write accesses to all CPU registers and memory mapped addresses (all accesses through the AHB-AP debug component).

RAM power and retention

In the nRF52 Series, the RAMON and RAMONB registers are deprecated. The RAM[x] registers in the POWER peripheral replace this functionality. Individual RAM sections can still be switched on or off in System-On mode, and retention can be switched on or off in System-Off mode. In addition, the FICR's NUMRAMBLOCK and SIZERAMBLOCKS registers are removed. RAM configuration can be derived from the Cortex-M4F ROM table part number, as it is static for a given part number.

nRF51 Series Memory Protection Unit replaced

The two-region MPU functionality in the nRF51 Series has been removed from the nRF52 Series. This should not be confused with the Cortex-M4Fs MPU. In the nRF52 Series the same functionality can be achieved with the memory watch unit (MWU), which is a more generic implementation. In addition, the block protect mechanism in the nRF51 Series (PROTEN registers) has been renamed as BPROT in the nRF52 Series.

NVM timing

The time it takes to do a page erase, mass erase and to write to non-volatile memory (NVM) has changed in the nRF52 Series. Please look up the new values in the electrical parameters section of the NVMC chapter in the nRF52 Product Specification.

Analog to Digital Converter (ADC) redesign

The ADC peripheral has been redesigned and is not compatible with the nRF51 Series ADC.