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

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
   

Note

Programming the nRF54H20 SoC can sometimes fail due to conflicts in the resource configuration. This can happen if, for example, an application programmed to the nRF54H20 SoC configured the UICRs for one or more cores in a way that is incompatible with the configuration required by the application you are trying to program on the SoC.

To fix this error and erase the UICR for the application core, run the following command:

nrfutil device recover --core Application

If your sample also uses the radio core, you must also erase the UICRs for the radio core. To erase the UICR for the radio core, run the following command:

nrfutil device recover --core Network

For more information on the command, run:

nrfutil device recover --help

You can then run west flash to program your application.

Testing

After programming the sample to your development kit for both cores, test it by performing the following steps:

1. Connect to the kit with a terminal emulator (for example, nRF Connect Serial Terminal). 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, we expect the following messages:

     *** 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, we can also see an ack_event, which is not passed to the host core.

Dependencies

This sample uses the following nRF Connect SDK subsystems:

• Application Event Manager

In addition, it uses the following Zephyr subsystems:

• include/ipc/ipc_service.h

• Logging