Peripheral interface

Peripherals are controlled by the CPU by writing to configuration registers and task registers. Peripheral events are indicated to the CPU by event registers and interrupts if they are configured for a given event.

Figure 1. Tasks, events, shortcuts, publish, subscribe and interrupts
Tasks, events, shortcuts, publish, subscribe and interrupts

Note: For more information on 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:

  • Some peripherals share some registers or other common resources.
  • Operation is mutually exclusive. Only one of the peripherals can be used at a time.
  • Switching from one peripheral to another must follow a specific pattern (disable the first, then enable the second peripheral).

Peripherals with shared ID

In general (with the exception of ID 0), peripherals sharing an ID and base address may not be used simultaneously. The user can only enable one peripheral at the time on this specific ID.

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

  • Disable the previously used peripheral.
  • Disable any publish/subscribe connection to the DPPI system for the peripheral that is being disabled.
  • Clear all bits in the INTEN register, i.e. INTENCLR = 0xFFFFFFFF.
  • Explicitly configure the peripheral that you are about to enable, and do not rely on configuration values that may be inherited from the peripheral that was disabled.
  • Enable the now configured peripheral.

See which peripherals are sharing ID in Instantiation.

Peripheral registers

Most peripherals feature an ENABLE register. Unless otherwise is specified in the chapter, 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 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 info on these retained registers' behavior, see chapter Reset.

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).

The SET register is used to set individual bits in the main register, while the CLR register is used to clear individual bits in the main register. Writing 1 to a bit in SET or CLR register will set or clear the same bit in the main register respectively. Writing 0 to a bit in 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 hence not directly accessible in all cases.

Tasks

Tasks are used to trigger actions in a peripheral, for example 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 Tasks, events, shortcuts, publish, subscribe and interrupts.

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 Tasks, events, shortcuts, publish, subscribe and interrupts). An event register is only cleared when firmware writes 0 to it. Events can be generated by the peripheral even when the event register is set to 1.

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.

Publish / Subscribe

Events and tasks from different peripherals can be connected together through the DPPI system. See Tasks, events, shortcuts, publish, subscribe and interrupts. This is done through publish / subscribe registers in each peripheral. 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 for details.

Interrupts

All peripherals support interrupts. Interrupts 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 Tasks, events, shortcuts, publish, subscribe and interrupts.

Interrupt clearing

Interrupts should always be cleared.

Clearing an interrupt by writing 0 to an event register, or disabling an interrupt using the INTENCLR register, may take a number of CPU clock cycles to take effect. This means that an interrupt may reoccur immediately, even if a new event has not come, if the program exits an interrupt handler after the interrupt is cleared or disabled but before it has taken effect.

Note: To avoid an interrupt reoccurring before a new event has come, the program should perform a read from one of the peripheral registers. For example, the event register that has been cleared, or the INTENCLR register that has been used to disable the interrupt.

Care should be taken to ensure that the compiler does not remove the read operation as an optimization.

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