Nordic Tasks and Events

This is an introduction to Nordic Semiconductor’s nRF52 series of Bluetooth Low Energy SoC (System on Chip) devices’ usage of Tasks and Events. The Nordic SoC Product Specification links are below.

TASKS

In embedded systems, the term ‘task’ almost always refers to a execution context. Example: “Is this running in a task or an interrupt?” Within the context of the Nordic nRF52 documentation the term TASKS has a completely different meaning.

TASKS are peripheral registers, that when written with value ‘1’ or triggered by hardware (see SHORTS and PPI below), will cause a peripheral to take some action. TASKS registers are write-only single-bit registers; reading a TASKS register will always return zero. Writing a ‘0’ to a TASKS register is not documented and therefore should be considered undefined behavior.

When writing a ‘1’ to a Nordic Peripheral TASK register some action will be taken. For example writing a ‘1’ to the UARTE peripheral TASKS_STARTRX register will initiate the UARTE peripheral to begin receiving data into its receive buffer.

In addition to writing a TASK register to trigger a peripheral to take a specific action a TASK can be triggered using an EVENT.

EVENTS

An EVENT is a peripheral register used to indicate to the firmware or hardware that something has happened. Nordic uses the term EVENT in a manner consistent with the ARM Cortex M/R series CPU usage. Nordic embraces the EVENT concept and then extends it for some spectacular performance.

An EVENT in its most familiar form is an interrupt. This might be the rising edge of a GPIO pin, or a transmit or receive completion event, or any other peripheral interrupt requiring service. In most cases an EVENT will be enabled and disabled through the use of the INTENSET and INTENCLR register. These are typical ARM peripheral interrupt enable/disable registers:

  • Writing bits to the value ‘1’ in the INTENSETregister will enable the EVENT to generate interrupts.
  • Writing bits to the value ‘1’ in the INTENCLRregister will disable the EVENT from generating interrupts.

These registers are can be read to determine the EVENT to interrupt enable state. There is often an INTEN register which can be used to enable and disable the EVENT to interrupt mapping, however it is not the preferred register to use. The INTENSET and INTENCLR register allow enable/disable without the software performing a read/modify/write operation on the register.

Once the ISR has been entered the interrupt status is determined by reading each of the EVENTS registers associated with the peripheral. EVENTS registers are single purpose booleans: their value is always ‘1’ or ‘0’. If set to ‘1’ then the EVENT has been triggered and the EVENTS register must be set to ‘0’. If the EVENTS register is ‘1’, and the EVENT is enabled to trigger an interrupt, then the ISR will be called repeatedly until the EVENTS register is either disabled or set to ‘0’.

When clearing any EVENT register the guidance found in the Nordic documentation must be followed. It is worth reading the nRF52 section 15.8.1 on your own, but I will quote the gist here:

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.

nRF52832 Product Specification v1.4 Section 15.8.1 Interrupt Clearing

SHORTS and PPI

Nordic has added another dimension to the concept of EVENTS. EVENTS can trigger peripheral TASKS directly without software intervention. This can be accomplished using 2 different methods

  • SHORTS
  • PPI Programmable Peripheral Interconnect

SHORTS are dedicated ‘shortcuts’ within a peripheral dedicated to connecting an EVENT to a TASK. Some peripherals which exploit the DMA double-buffering feature have dedicated shortcuts to enqueue the next DMA buffer immediately after the previous buffer has filled or emptied. The UARTE, TWIM, TWIS, SPIS, SPIM peripherals all have a SHORTS register which allows some EVENT to trigger a TASK. Consider the power of this capability: Using double-buffered DMA, which starts a subsequent transaction each time a transaction completes, without the latency of ISR handling. The difficult part of hard real-time performance is now handled in hardware.

The PPI allows for cross-peripheral TASK to EVENT hardware based triggering without software intervention. This is just as powerful as the peripheral short cut approach but maps across all peripherals.

Nordic PPI logical schematic

nRF52832 Product Specification v1.4
Section 22 Programmable peripheral interconnect

Any EVENT from any peripheral can be set to trigger any two TASKS withing the Nordic SoC. The versatility and power of this topology is a work of art. I think Nordic has set the bar in the Cortex M/R embedded world with this.

Consider this example:

  • A timer based comparator is used to start the acquisition of ADC set of samples.
  • The ADC performs the conversion and places the result in a destination buffer.
  • Once the ADC has completed the conversion, a SPI master takes the result and transfers the data off to another device to get the ADC sample group.

Using TASKS, EVENTS and the PPI this operation to be performed without waking up the Nordic Cortex-M4 processor.

The chaining of TASKS to EVENTS does not have to stop there. Additionally, PPI channel and groups of channels can be enabled and disabled through, wait for it … TASKS and EVENTS. In other words, based on EVENTS and without software intervention, the PPI routing can be changed.

Think about what Nordic has done here. Think about why they do it. In Bluetooth they are sending and receiving packets which require encryption and decryption. They have TASKS and EVENTS dedicated to this purpose. I imagine that they can perform so much of their radio and link layer IO without CPU intervention. These transactions are, in my speculative estimation, based on TASKS and EVENTS. And these structures are flexible. As their design evolves and the Bluetooth specification grows with features they can accommodate these without hardware changes – or at least better than most designs.

Published by natersoz

Electrical Engineer from Rose-Hulman

Leave a comment