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 an application 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 with Visual Studio Code, follow the steps listed on the How to build an application page in the nRF Connect for VS Code extension documentation. See Configuring and building an application for other building scenarios, Programming an application for programming steps, and Testing and optimization for general information about testing and debugging in the nRF Connect SDK.

Complete the following steps to program the sample:

  1. Go to the sample directory.

  2. Open the command line terminal.

  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

    west build -b nrf54h20dk/nrf54h20/cpuapp -- -Devent_manager_proxy_SNIPPET=nordic-ppr
    

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

In addition, it uses the following Zephyr subsystems:

  • include/ipc/ipc_service.h

  • Logging