Feedback
Feedback

If you are having issues with the exercises, please create a ticket on DevZone: devzone.nordicsemi.com
Drag & Drop Files, Choose Files to Upload You can upload up to 2 files.

Event system and DPPI

Event system

The event system enables peripherals to interact with each other autonomously, meaning they can communicate and trigger actions without requiring intervention from the CPU. For instance, we can use a timer to trigger an ADC sampling, so that the CPU does not need to execute instructions to trigger sampling.

This autonomous interaction occurs through tasks and events. Tasks are inputs that initiate a peripheral’s functionality, while events are outputs generated by a peripheral to signal that something has occurred, such as a state change.

If you are already familiar with standard microcontrollers (MCUs), you know that peripherals typically come with control and status registers. However, Nordic Semiconductor’s architecture has a key differentiating feature – the approach is further refined by breaking down each specific control action into a task, with each task mapped to a dedicated task register.

Similarly, the various states represented by the status register are broken down into events, with each distinct state mapped to a specific event register. Learn more about Peripheral interface.

Event system benefits

The event system in Nordic SoCs enables direct communication between peripherals such as ADCs, TIMERs, GPIOTE, and others. This hardware-based approach reduces CPU wake-ups and removes the need for frequent software interrupts. The event system brings the following advantages:

  • Reduced and predictable latency – Handling events at the hardware level is much faster and more predictable than using software-managed interrupts. Reduced latency results in faster peripheral response.
  • Reduced Power Consumption – If the CPU remains asleep instead of waking to handle peripheral interrupts, larger parts of the SoC stay asleep longer, resulting in energy savings.
  • Simplified Firmware – With fewer interrupts and CPU context switching to handle them, the firmware is simpler and cleaner.

Distributed Programmable Peripheral Interconnect (DPPI)

The event system for the nRF54L Series is primarily built around the Distributed Programmable Peripheral Interconnect (DPPI) system. The DPPI basically provides channels for signaling between peripherals.

Think of the channel as a programmable hardware link. The start of the link connects to the event register, and the end connects to the task register. There’s a switch on the hardware link; when the switch is turned on (channel enabled) and a signal appears in the event register, it travels through the link and activates the task register. This then triggers the related control logic.

Each DPPI channel is identified by a unique Channel Index (CHIDX), ranging from 0 to 255. Each power domain has its own DPPI; individual channels can be enabled or disabled through the DPPI Controller (DPPIC) available in each domain. The following table lists the DPPI per domain, its controller, and the number of channels in each.

Power DomainDPPIC Instance# of DPPI Channels (nRF54L15 | nRF54L10 | nRF54L05)# of DPPI Channels (nRF54LM20A | nRF54LM20B | nRF54LV10A)
MCUDPPIC00816
RADIODPPIC102424
PERIDPPIC201616
LPDPPIC3044

DPPI supports a publish and subscribe mechanism that allows for flexible connection options, including one-to-one, one-to-many, many-to-one, and many-to-many. Learn more about DPPI.

Cross-Domain Communication

DPPI channels within a power domain can be bridged to channels in different power domains using PPI Bridges (PPIB). PPIB channels are fixed, point-to-point, and unidirectional connections that link DPPI channels in a separate domain. For example, PPIB00 bridges channels between the MCU and RADIO domains, and PPIB01 between MCU and PERI domains.

PPIB on the nRF54L15 | nRF54L10 | nRF54L05
PPIB on the nRF54LM20A | nRF54LM20B | nRF54LV10A

When peripherals reside in different power domains and communicate using DPPI Bridges (PPIB), additional access latency will apply. This additional latency may arise because DPPI signals operate on different clock sources across domains.

Also, if either the generating or receiving power domains are sleeping, there will be a wake-up latency. To improve latency in this situation, you can use the Constant Latency mode (power domains are kept on). However, enabling Constant Latency mode will result in increased power consumption. Learn more about PPIB.

Switch language?

Progress is tracked separately for each language. Switching will continue from your progress in that language or start fresh if you haven't begun.

Your current progress is saved, and you can switch back anytime.

Register an account
Already have an account? Log in
(All fields are required unless specified optional)

  • 8 or more characters
  • Upper and lower case letters
  • At least one number or special character

Forgot your password?
Enter the email associated with your account, and we will send you a link to reset your password.