Peripheral interface

Peripherals are controlled by the CPU through configuration registers, as well as task and event registers. Task registers are inputs, enabling the CPU and other peripherals to initiate a functionality. Event registers are outputs, enabling a peripheral to trigger tasks in other peripherals and/or the CPU by tying events to CPU interrupts.

Figure 1. Peripheral interface
Peripheral interface

The distributed programmable peripheral interconnect (DPPI) feature enables peripherals to connect events to tasks without CPU intervention.

Note: For more information on DPPI and the DPPI channels, see DPPI - Distributed programmable peripheral interconnect.

Peripheral ID

Every peripheral is assigned a fixed block of 0x1000 bytes of address space, which is equal to 1024 x 32 bit registers.

See Instantiation for more information about which peripherals are available and where they are located in the address map.

There is a direct relationship between peripheral ID and base address. For example, a peripheral with base address 0x40000000 is assigned ID=0, a peripheral with base address 0x40001000 is assigned ID=1, and a peripheral with base address 0x4001F000 is assigned ID=31.

Peripherals may share the same ID, which may impose one or more of the following limitations:

  • Shared registers or common resources
  • Limited availability due to mutually exclusive operation; only one peripheral in use at a time
  • Enforced peripheral behavior when switching between peripherals (disable the first peripheral before enabling the second)

Peripherals with shared ID

In general (with the exception of ID 0), peripherals sharing an ID and base address may not be used simultaneously. Only one peripheral can be enabled at a given ID.

When switching between two peripherals sharing an ID, the following should be performed to prevent unwanted behavior:

  1. Disable the previously used peripheral.
  2. Disable any publish/subscribe connection to the DPPI system for the peripheral that is being disabled.
  3. Clear all bits in the INTEN register, i.e. INTENCLR = 0xFFFFFFFF.
  4. Explicitly configure the peripheral being enabled. Do not rely on inherited configuration from the disabled peripheral.
  5. Enable the now configured peripheral.

For a list of which peripherals that share an ID see Instantiation.

Peripheral registers

Most peripherals feature an ENABLE register. Unless otherwise specified, the peripheral registers must be configured before enabling the peripheral.

PSEL registers need to be set before a peripheral is enabled or started. Updating PSEL registers while the peripheral is running has no effect. In order to connect a peripheral to a different GPIO, the peripheral must be disabled, the PSEL register updated, and the peripheral re-enabled. It takes four CPU cycles between the PSEL register update and the connection between a peripheral and a GPIO becoming effective.

Note: Note that the peripheral must be enabled before tasks and events can be used.

Most of the register values are lost during System OFF or when a reset is triggered. Some registers will retain their values in System OFF or for some specific reset sources. These registers are marked as retained in the register description for a given peripheral. For more information on their behavior, see chapter RESET - Reset control.

Bit set and clear

Registers with multiple single-bit bit fields may implement the set-and-clear pattern. This pattern enables firmware to set and clear individual bits in a register without having to perform a read-modify-write operation on the main register.

This pattern is implemented using three consecutive addresses in the register map, where the main register is followed by dedicated SET and CLR registers (in that exact order).

In the main register, the SET register sets individual bits and the CLR register clears them. Writing '1' to a bit in the SET or CLR register will set or clear the same bit in the main register respectively. Writing '0' to a bit in the SET or CLR register has no effect. Reading the SET or CLR register returns the value of the main register.

Note: The main register may not be visible and therefore not directly accessible in all cases.

Tasks

Tasks are used to trigger actions in a peripheral, such as to start a particular behavior. A peripheral can implement multiple tasks with each task having a separate register in that peripheral's task register group.

A task is triggered when firmware writes '1' to the task register, or when the peripheral itself or another peripheral toggles the corresponding task signal. See the figure Figure 1.

Events

Events are used to notify peripherals and the CPU about events that have happened, for example a state change in a peripheral. A peripheral may generate multiple events, where each event has a separate register in that peripheral's event register group.

An event is generated when the peripheral itself toggles the corresponding event signal, and the event register is updated to reflect that the event has been generated, see figure Figure 1. An event register is cleared when a '0' is written to it by firmware. Events can be generated by the peripheral even when the event register is set to '1'.

Publish and subscribe

Events and tasks from different peripherals can be connected together through the DPPI system using the PUBLISH and SUBSCRIBE registers in each peripheral. See Figure 1. An event can be published onto a DPPI channel by configuring the event's PUBLISH register. Similarly, a task can subscribe to a DPPI channel by configuring the task's SUBSCRIBE register.

See DPPI - Distributed programmable peripheral interconnect for details.

Shortcuts

A shortcut is a direct connection between an event and a task within the same peripheral. If a shortcut is enabled, the associated task is automatically triggered when its associated event is generated.

Using shortcuts is equivalent to making the connection outside the peripheral and through the DPPI. However, the propagation delay when using shortcuts is usually shorter than the propagation delay through the DPPI.

Shortcuts are predefined, which means that their connections cannot be configured by firmware. Each shortcut can be individually enabled or disabled through the shortcut register, one bit per shortcut, giving a maximum of 32 shortcuts for each peripheral.

Interrupts

All peripherals support interrupts which are generated by events.

A peripheral only occupies one interrupt, and the interrupt number follows the peripheral ID. For example, the peripheral with ID=4 is connected to interrupt number 4 in the nested vectored interrupt controller (NVIC).

Using registers INTEN, INTENSET, and INTENCLR, every event generated by a peripheral can be configured to generate that peripheral's interrupt. Multiple events can be enabled to generate interrupts simultaneously. To resolve the correct interrupt source, the event registers in the event group of peripheral registers will indicate the source.

Some peripherals implement only INTENSET and INTENCLR registers, and the INTEN register is not available on those peripherals. See the individual peripheral chapters for details. In all cases, reading back the INTENSET or INTENCLR register returns the same information as in INTEN.

Each event implemented in the peripheral is associated with a specific bit position in the INTEN, INTENSET, and INTENCLR registers.

The relationship between tasks, events, shortcuts, and interrupts is illustrated in figure Figure 1.

Interrupt clearing and disabling

Interrupts should always be cleared by writing '0' to the corresponding EVENT register.

Until cleared, interrupts will immediately be re-triggered and cause software interrupt service routines to be executed repeatedly.

Because the clearing of the EVENT register may take a number of CPU clock cycles, the program should perform a read from the EVENT register that has been cleared before exiting the interrupt service routine. This will ensure that the EVENT clearing has taken place before the interrupt service routine is exited. Care should be taken to ensure that the compiler does not remove the read operation as an optimization.

Similarly, when disabling an interrupt inside an interrupt service routine, the program should perform a read from the INTEN or INTENCLR registers to ensure that the interrupt is disabled before exiting the interrupt service routine.

Secure/non-secure peripherals

For some peripherals, the security configuration can change from secure to non-secure, or vice versa. Care must be taken when changing the security configuration of a peripheral, to prevent security information leakage and ensure correct operation.

The following sequence should be followed, where applicable, when configuring and changing the security settings of a peripheral in the SPU — System protection unit:

  1. Stop peripheral operation
  2. Disable the peripheral
  3. Remove pin connections
  4. Disable DPPI connections
  5. Clear sensitive registers (e.g. writing back default values)
  6. Change peripheral security setting in the SPU — System protection unit
  7. Re-enable the peripheral

This document was last updated on
2019-12-09.
Please send us your feedback about the documentation! For technical questions, visit the Nordic Developer Zone.