Event Manager Proxy

The Event Manager Proxy sample demonstrates how to use Event Manager Proxy to transport events between remote and host cores. The sample also demonstrates the proposed application structure where common events declarations and definitions are available for both cores.

Requirements

The sample supports the following development kits:

Hardware platforms

PCA

Board name

Board target

nRF9251 DK

nrf9251dk

nrf9251dk/nrf9251/cpuapp

nRF54LV10 DK

PCA10188

nrf54lv10dk

nrf54lv10dk/nrf54lv10a/cpuapp

nRF54LM20 DK

PCA10184

nrf54lm20dk

nrf54lm20dk/nrf54lm20b/cpuapp nrf54lm20dk/nrf54lm20a/cpuapp

nRF54LC10 DK

PCA10226

nrf54lc10dk

nrf54lc10dk/nrf54lc10a/cpuapp

nRF54L15 DK

PCA10156

nrf54l15dk

nrf54l15dk/nrf54l15/cpuapp

nRF54H20 DK

PCA10175

nrf54h20dk

nrf54h20dk/nrf54h20/cpuapp

nRF5340 DK

PCA10095

nrf5340dk

nrf5340dk/nrf5340/cpuapp

Overview

The proxy sample copies the functionality from Application Event Manager sample, but splits it between the two cores. The remote core runs the simulated sensor module, while the host core takes care of configuration and calculates statistics.

The sample uses modules from Application Event Manager sample, which communicate using events:

Sensor (sensor_simulated.c):

This module waits for a configuration event (which is sent by main.c). After receiving this event, it simulates measured data at constant intervals. Every time the data is updated, the module sends the current values as measurement event. When the module receives a control event from the Controller, it responds with an ACK event.

Controller (controller.c):

This module waits for measurement events from the sensor. Every time a measurement event is received, the module checks one of the measurement values that are transmitted as part of the event and, if the value exceeds a static threshold, sends a control event.

Statistics (stats.c):

This module waits for measurement events from the sensor. The module calculates and logs basic statistics about one of the measurement values that are transmitted as part of the event.

The only change compared with the Application Event Manager sample modules is that the Statistic module now also counts control messages. This change allows to transfer different range of messages between cores.

File and directory layout

The application is divided into host and remote. The host configuration is placed directly in the samples/event_manager_proxy folder. The remote configuration is placed in the samples/event_manager_proxy/remote folder. The remote configuration is added to the host as a subproject, which means that it builds as part of the host application build.

Both the remote and the host use common event declarations and definitions that are located in the samples/event_manager_proxy/common_events folder, and modules that are located in the samples/event_manager_proxy/modules folder.

Configuration

See Configuring and building for information about how to permanently or temporarily change the configuration.

Selecting ICMSG backend

On the nRF5340 DK, this sample uses by default the OpenAMP backend provided by the IPC Service. You can instead select the ICMSG backend configuration, which has smaller memory requirements.

The ICMSG backend configuration is provided in the prj_icmsg.conf file. To provide the ICMSG backend configuration, specify the -DFILE_SUFFIX=icmsg parameter along with the build command when building the sample:

west build -p -b nrf5340dk/nrf5340/cpuapp -- -DFILE_SUFFIX=icmsg

The nRF54H20 target supports only ICMSG backend.

Building and running

This sample can be found under samples/event_manager_proxy in the nRF Connect SDK folder structure.

To build the sample, follow the instructions in Building an application for your preferred building environment. See also Programming an application for programming steps and Testing and optimization for general information about testing and debugging in the nRF Connect SDK.

Note

When building repository applications in the SDK repositories, building with sysbuild is enabled by default. If you work with out-of-tree freestanding applications, you need to manually pass the --sysbuild parameter to every build command or configure west to always use it.

When building this sample with Sysbuild for an SoC that has a network core, the IPC radio firmware is automatically applied to the build. The IPC radio is one of the companion components in the nRF Connect SDK and allows to use the radio peripheral from another core in a multicore device. If needed, you can modify the IPC radio configuration in the prj.conf source file in the sample’s remote/ directory.

Complete the following steps to program the sample:

  1. Go to the sample directory.

  2. Start the toolchain environment in a terminal window.

  3. Run the following command to build the application code for the host and the remote:

    nRF5340 DK

    west build -b nrf5340dk/nrf5340/cpuapp

    nRF54H20 DK

    A snippet for running the PPR core is added automatically to build configuration.

    west build -b nrf54h20dk/nrf54h20/cpuapp

    or use twister test case:

    west build -b nrf54h20dk/nrf54h20/cpuapp -T sample.event_manager_proxy.nrf54h20dk_cpuapp .

  4. Program both the cores:

    west flash

Testing

After programming the sample to your development kit, complete the following steps to test it:

  1. Connect to the kit with a terminal emulator (for example, the Serial Terminal app). See Testing and optimization for the required settings and steps.

  2. Reset the kit.

  3. Observe that output logged on two UART serial terminals. One for the host and the other for the remote core.

    • On the host core, the following messages are expected:

      *** Booting Zephyr OS build v2.7.99-ncs1-17-gc3208e7ff49d  ***
Event Manager Proxy demo started
[00:00:00.284,881] <inf> event_manager: e:config_event init_val_1=3
[00:00:00.285,430] <inf> event_manager: e:measurement_event val1=3 val2=3 val3=3
[00:00:00.785,675] <inf> event_manager: e:measurement_event val1=3 val2=6 val3=9
[00:00:01.285,949] <inf> event_manager: e:measurement_event val1=3 val2=9 val3=18
[00:00:01.786,254] <inf> event_manager: e:measurement_event val1=3 val2=12 val3=30
[00:00:02.286,560] <inf> event_manager: e:measurement_event val1=3 val2=15 val3=45
[00:00:02.286,682] <inf> event_manager: e: control_event
[00:00:02.286,682] <inf> stats: Control event count: 1
[00:00:02.787,017] <inf> event_manager: e:measurement_event val1=-3 val2=12 val3=57
[00:00:03.287,322] <inf> event_manager: e:measurement_event val1=-3 val2=9 val3=66
[00:00:03.787,597] <inf> event_manager: e:measurement_event val1=-3 val2=6 val3=72
[00:00:04.287,872] <inf> event_manager: e:measurement_event val1=-3 val2=3 val3=75
[00:00:04.788,177] <inf> event_manager: e:measurement_event val1=-3 val2=0 val3=75
[00:00:04.788,208] <inf> stats: Average value3: 45
[00:00:05.288,452] <inf> event_manager: e:measurement_event val1=-3 val2=-3 val3=72
[00:00:05.788,726] <inf> event_manager: e:measurement_event val1=-3 val2=-6 val3=66
[00:00:06.289,031] <inf> event_manager: e:measurement_event val1=-3 val2=-9 val3=57
[00:00:06.789,306] <inf> event_manager: e:measurement_event val1=-3 val2=-12 val3=45
[00:00:07.289,611] <inf> event_manager: e:measurement_event val1=-3 val2=-15 val3=30
[00:00:07.289,733] <inf> event_manager: e: control_event
[00:00:07.289,733] <inf> stats: Control event count: 2

      The host starts the communication by sending a config_event, which is also received and processed by the remote core.

    • On the remote core following messages are expected:

      *** Booting Zephyr OS build v2.7.99-ncs1-17-gc3208e7ff49d  ***
Event Manager Proxy remote_core started
[00:00:00.010,864] <inf> event_manager: e:config_event init_val_1=3
[00:00:00.011,047] <inf> event_manager: e:measurement_event val1=3 val2=3 val3=3
[00:00:00.511,322] <inf> event_manager: e:measurement_event val1=3 val2=6 val3=9
[00:00:01.011,566] <inf> event_manager: e:measurement_event val1=3 val2=9 val3=18
[00:00:01.511,871] <inf> event_manager: e:measurement_event val1=3 val2=12 val3=30
[00:00:02.012,176] <inf> event_manager: e:measurement_event val1=3 val2=15 val3=45
[00:00:02.012,298] <inf> event_manager: e: control_event
[00:00:02.012,451] <inf> event_manager: e: ack_event
[00:00:02.512,634] <inf> event_manager: e:measurement_event val1=-3 val2=12 val3=57
[00:00:03.012,939] <inf> event_manager: e:measurement_event val1=-3 val2=9 val3=66
[00:00:03.513,244] <inf> event_manager: e:measurement_event val1=-3 val2=6 val3=72
[00:00:04.013,488] <inf> event_manager: e:measurement_event val1=-3 val2=3 val3=75
[00:00:04.513,793] <inf> event_manager: e:measurement_event val1=-3 val2=0 val3=75
[00:00:05.014,099] <inf> event_manager: e:measurement_event val1=-3 val2=-3 val3=72
[00:00:05.514,343] <inf> event_manager: e:measurement_event val1=-3 val2=-6 val3=66
[00:00:06.014,648] <inf> event_manager: e:measurement_event val1=-3 val2=-9 val3=57
[00:00:06.514,953] <inf> event_manager: e:measurement_event val1=-3 val2=-12 val3=45
[00:00:07.015,197] <inf> event_manager: e:measurement_event val1=-3 val2=-15 val3=30
[00:00:07.015,350] <inf> event_manager: e: control_event
[00:00:07.015,502] <inf> event_manager: e: ack_event

Now all the measurement and control events are generated on the remote core and passed to the host core, where the statistics are generated. On the remote core, you can also see an ack_event that is not passed to the host core.

Dependencies

This sample uses the following nRF Connect SDK subsystems:

In addition, it uses the following Zephyr subsystems:

  • include/ipc/ipc_service.h

  • Logging