MCUSW
Cdd Ipc User Guide

Introduction

This document details Cdd Ipc module implementations

  • Supported AUTOSAR Release : 4.3.1
  • Supported Configuration Variants : Pre-Compile
  • Vendor ID : CDD_IPC_VENDOR_ID (44)
  • Module ID : CDD_MODULE_ID (255)

Cdd Ipc modules allows core hosting MCAL/AUTOSAR to communicate with other cores (processing entities, with-in SoC) hosting PDK based IPC driver as well as HLOS Linux IPC driver. This driver could be used to transmit and receive variable length messages between cores, via logical communication channel ID's. Can be mapped to Sender-Receiver AUTOSAR interface, for data oriented communication between core that host AUTOSAR / NON AUTOSAR processing entities.

Some of key points to note

  1. Can inter-operate with PDK IPC and Linux IPC drivers for jacinto variants.
  2. Depends on the built-in mailbox hardware to notify arrival of new message
  3. Relies on shared memory (message would be copied into shared area and destination core notified, the destination core would read this message)
  4. Not configurable (via Cdd Ipc configuration parameters) to use different mailbox, FIFO & user
  5. Interrupt are used, to signal presence of new message destined to this core
  6. For a given channel local and remote endpoint pair is formed.
  7. In case of communication with Linux, remote endpoint is not published upfront, hence it is cached everytime a message a received.
  8. Refer IPC CDD Profiled Performance to determine the CPU Hz need to transport / receive a message

Cdd Driver Architecture/Design

Please refer the Cdd IPC design page, which is part of CSP.[2]

Functional Description

demo_cdd_ipc_ctrl_ep.png
Cdd Ipc Architecture

As depicted in architecture figure above, Cdd Ipc implementation relies on mailbox, shared memory to transport messages between cores. The shared memory & other associated memories are provided via the configurator, Refer [Shared Memory Configuration] (Refer to Design Document provided in CSP) for details.

It's recommended to not change the recommended configuration for these parameters, unless the user comprehends methods to change memory location (and/or size) of the shared memory.

Communication Channel

A communication channel provides a logical communication channel between two processors. Identified uniquely by an un-signed sequential integer, represented by configurator defined [symbolic name] (Refer to Design Document provided in CSP).

  • Refer for Baremetal/NORTOS Application (SDK Install Directory)/mcusw.xx.yy.zz.bb/mcal_drv/mcal/examples_config/CddIpc_Demo_Cfg/output/generated/include/Cdd_IpcCfg.h for the generated communication channel identifiers.
  • Refer for Linux Application (SDK Install Directory)/mcusw.xx.yy.zz.bb/mcal_drv/mcal/examples_config/CddIpcLinux_Demo_Cfg/output/generated/include/Cdd_IpcCfg.h for the generated communication channel identifiers

There could be multiple unique communication channel between any given 2 cores.

End Point

There are two primary identifiers, identifying the end-points for a core. This is used by the driver to identify the source / destination of a message.

  • LocalEp : An unique, non-repetitive integer on the core that hosts MCAL/AUTOSAR
  • RemoteProcId : An unique processor identifiers, which determines the core that this communication channel is associated with (i.e. to be able to send and receive message to / from that core)
  • RemoteEp : An unique, non-repetitive integer on the remote core

Notes on EndPoints

  1. Shall be unique on a core (either local or remote cores)
  2. Need not be same i.e. localEp = X and remoteEp = Y, is a valid
  3. A communication channel shall have unique end-points, i.e. localEp shall be unique and on remote cores, remoteEp shall be unique

Buffer for each channel

  • MaxNumMsgQueued : Number of messages that could potentially be received & queued in the driver before, these messages could be received by applications
  • MaxMsgSize : Size of the largest message that could be received The MaxNumMsgQueued & MaxMsgSize is used to determine the memory reserved by the driver. The memory is reserved in (SDK Install Directory)/mcusw.xx.yy.zz.bb/mcal_drv/mcal/examples_config/CddIpc_Demo_Cfg/output/generated/src/Cdd_IpcCfg.c with variable (s) Cdd_IpcCommChBuf_<Channel ID>

Message reception process

  • Remote core sends a message
  • An interrupt occurs on the host core (On which MCAL AUTOSAR code is running)
  • Checks MBOX_IRQSTATUS_RAW register (BASE_ADDR + 0x100 + (n*16U)), corresponding mailbox bit is set if there is a message in MBOX.
  • Checks MBOX_MSGSTATUS register (BASE_ADDR + 0xC0 + (n*4U)), gives the number of messages available in MBOX.
  • Reads MBOX_MSG register (BASE_ADDR + 0x40 + (n*4U)), gives message written in MBOX. Transmitting core usually writes the remote core ID (core meant for message reception).
  • Clear interrupt by writing 1 to MBOX_IRQSTATUS_CLR (BASE_ADDR + 0x104 + (n*16U)) registers corresponding bit.
  • Read the actual message written in VRING.

Message transmission process

  • Write actual message to VRING.
  • Check if FIFO of specific MBOX is not already full in MBOX_FIFOSTATUS register (BASE_ADDR + 0x80 + (n*4U)), if FIFO is full bit 0 will be set else it will be cleared.
  • Write a message in MBOX via MBOX_MSG register (BASE_ADDR + 0x40 + (n*4U)), usually remote core ID is written (core meant for message reception).

Control End Point

The demo application by default uses control channel/Announce API's to notify remote cores of service availability. This feature could be turned OFF Refer for steps to turn OFF It is an endpoint which can be used to send or receive control messages, primarily used by Announce API�s to notify remote cores about the availability of service.

Back To Top

Interrupt to ISR mapping for jacinto variants

Please refer to the SOC User Manual for detail.

Back To Top

Configuration

The design document details the various configurable parameters of this implementation, please refer section Configurator of [2] (Refer to Design Document provided in CSP)

Back To Top

Non Standard Service APIs

Cdd_IpcRegisterReadBack

As noted from the previous MCAL implementation, some of the critical configuration registers could potentially be corrupted by other entities (s/w or h/w). One of the recommended detection methods would be to periodically read-back the configuration and confirm configuration is consistent. The service API defined below shall be implemented to enable this detection

Description Comments
Service Name Cdd_IpcRegisterReadBack Can potentially be turned OFF (Refer to Design Document provided in CSP)
Syntax uint32 Cdd_IpcRegisterReadBack ( uint32 remoteProcId, P2VAR(Cdd_IpcRegRbValues, AUTOMATIC, CDD_APP_DATA) pRegArgs) E_OK: Register read back has been done, E_NOT_OK: Register read back failed
Service ID NA
Sync / Async Sync
Reentrancy Reentrant
Parameter in remoteProcId Remote Processor ID.
Parameters out pRegArgs - Pointer to where to store the readback values. If this pointer is NULL_PTR, then the API will return E_NOT_OK.
Return Value Std_ReturnType E_OK, E_NOT_OK

Cdd_IpcGetMailboxStatus

Service to get Mailbox state is FULL or not

Description Comments
Service Name Cdd_IpcGetMailboxStatus Service to get Mailbox state is FULL or not
Syntax uint32 Cdd_IpcGetMailboxStatus(uint32 chId) E_OK: Register read back has been done, E_NOT_OK: Register read back failed
Service ID CDD_IPC_SID_MAILBOX_STATE
Sync / Async Sync
Reentrancy Reentrant
Parameter in remoteProcId Remote ID.
Parameters out None
Return Value uint32 Returns the mailbox state

Back To Top

Power-up

The driver doesn't configure the functional clock and power for the Mailbox module. It is expected that the Secondary Bootloader (SBL) powers up the required modules. Please refer SBL documentation.

Note that, this implementation will NOT reset the Mailbox. Un Expected/stale messages could be delivered by the driver. It's recommended to drain stale messages before announcing the availability via service API Cdd_IpcAnnounce () if enabled.

Back To Top

Build and Running for CDD_IPC Application for jacinto variants

Please follow steps detailed in section (Build) to build library or example.

Build MCAL example application for jacinto variants

The MCAL example application could be built with the command

$ cd (SDK Install Directory)/mcusw.xx.yy.zz.bb/build
$ make cdd_ipc_app CORE=(CORE) BOARD=(SOC)_evm SOC=(SOC) -sj

The possible variable values are

  • CORE_VARIABLE = mcu2_1, mcu1_0
  • SOC = j721e, j7200, j784s4,j742s2, j721s2
  • The generated executable is available at
    • (SDK Install Directory)/mcusw.xx.yy.zz.bb/binary/cdd_ipc_app/bin/(SoC)_evm/cdd_ipc_app_(CORE)_(BUILD_PROFILE).xer5f

Build MCAL example application for Linux communication

Navigate to /build/Rules.make and set the CDD_IPC_LINUX_BUILD to yes The MCAL example application could be built with the command

$ cd (SDK Install Directory)/mcusw.xx.yy.zz.bb/build
$ make cdd_ipc_app_rc_linux CORE=(CORE_VARIABLE) BOARD=(SOC)_evm SOC=(SOC) CDD_IPC_LINUX_BUILD=yes -sj

The possible variable values are

  • CORE_VARIABLE = mcu2_1, mcu1_0
  • SOC = j721e, j7200 , j721s2, j784s4,j742s2
  • The generated executable is available at
    • (SDK Install Directory)/mcusw.xx.yy.zz.bb/binary/cdd_ipc_app_rc_linux/bin/(SoC)_evm/cdd_ipc_app_rc_linux_(CORE_VARIABLE)_(BUILD_PROFILE).xer5f

Building the remote core example application

The remote core application implementation is available at (SDK Install Directory)/mcusw.xx.yy.zz.bb/mcuss_demos/inter_core_comm/ipc_remote

Note: You can build remote core applications with freertos. Ensure to use the same OS example and remote core application.

$ cd (SDK Install Directory)/mcusw.xx.yy.zz.bb/build
$ make -s ipc_remote_app CORE=mcu2_0 BOARD=(SOC)_evm SOC=(SOC) BUILD_OS_TYPE=freertos
  1. use IpcRemoteApp_DstProc = IPC_MCU2_1 in mcusw/mcuss_demos/inter_core_comm/ipc_remote/main_rtos.c for cdd_ipc_app on MCU2_1 core communicating to remote app on MCU2_0
  2. use IpcRemoteApp_DstProc = IPC_MCU1_0 in mcusw/mcuss_demos/inter_core_comm/ipc_remote/main_rtos.c for cdd_ipc_app on MCU1_0 core communicating to remote app on MCU2_0

Please follow steps detailed in section (Build) to build library or example

  1. Note: There is no special remote app needed for Linux communication/testing.
  2. Linux rpmsg_sample_client app can be used.

Building the MCAL IPC profiling application

Refer IPC Profiling Application for details on the profiling application.

$ cd (SDK Install Directory)/mcusw.xx.yy.zz.bb/build
$ make cdd_ipc_profile_app CORE=mcu1_0 BUILD_OS_TYPE=freertos -sj
  • The generated executable is available at
    • (SDK Install Directory)/mcusw.xx.yy.zz.bb/binary/cdd_ipc_profile_app_(BUILD_OS_TYPE)/bin/(SOC)_evm/cdd_ipc_profile_app_(BUILD_OS_TYPE)_mcu1_0_release.xer5f
  • constraints:
    • Profile app only works on J721E
    • Can only communicate with ipc_remote_app on MCU2_1 core. Refer to building remote core app but build on MCU2_1 core.

Back To Top

Building the MCAL IPC profiling application for Linux communication

Refer IPC Profiling Application for details on the profiling application.

$ cd (SDK Install Directory)/mcusw.xx.yy.zz.bb/build
$ make cdd_ipc_profile_app_rc_linux CORE=mcu1_0 BUILD_OS_TYPE=freertos CDD_IPC_LINUX_BUILD=yes -sj
  • The generated executable is available at
    • (SDK Install Directory)/mcusw.xx.yy.zz.bb/binary/cdd_ipc_profile_app_rc_linux/bin/(SoC)_evm/cdd_ipc_profile_app_rc_linux_mcu1_0_(BUILD_PROFILE).xer5f

Back To Top

Build MCAL Unit Test application

The MCAL Unit Test application could be built with the command

$ cd (SDK Install Directory)/mcusw.xx.yy.zz.bb/build
$ make -s cdd_ipc_test BOARD=(SOC)_evm SOC=(SOC) BUILD_PROFILE=release CORE=mcu2_1 BUILD_OS_TYPE=baremetal MCAL_CONFIG=x
CDD IPC(2_1) config_1 config_2 config_3 config_4 config_5
REMOTE(2_0) ipc_remote_app ipc_remote_app ipc_remote_2chnls_app ipc_remote_app ipc_remote_test1
  • The generated executable is available at
    • (SDK Install Directory)/mcusw.xx.yy.zz.bb/binary/cdd_ipc_app/bin/(SoC)_evm/cdd_ipc_app_mcu2_1_(BUILD_PROFILE).xer5f

Back To Top

Steps to run example application

To run the CddIpcApp for RTOS to RTOS on MCU2_1 core

  1. After loading javascript file in CCS scripting console, run the app that shows up in MCU_R5_0, which will enable mcu2_0 , mcu2_1 core binaries to load
  2. Connect to MAIN_R5_0_0 and MAIN_R5_0_1 (right click and connect)
  3. Connect MAIN_UART to get print on terminal after running applications
  4. Load ipc_remote_app binary to MAIN_R5_0_0 and load cdd_ipc_app binary to MAIN_R5_0_1. Can be done in any order
  5. Make sure to run cdd_ipc_app first, then ipc_remote_app

To run the CddIpcApp for RTOS to RTOS on MCU1_0 core

  1. After loading javascript file in CCS scripting console, load cdd_ipc_app on MCU_R5_0 core
  2. Connect to MAIN_R5_0_0 core (right click and connect)
  3. Connect MCU_UART to get print on terminal after running applications
  4. Load ipc_remote_app binary to MAIN_R5_0_0
  5. Run cdd_ipc_app first then ipc_remote_app

To run the CddIpcRprocLinuxApp on mcu1_0

  1. Download and install the Linux installer
  2. Partition and flash the SD card using the below mentioned steps
  3. For updating MCU (DM) R5F firmware binary, tispl.bin needs to be recompiled with the new firmware binary as mentioned below :
    • Replace the existing R5F MCU (DM) firmware binary with the new one by replacing (path_to_linux_installer)/board-support/prebuilt-images/ti-dm/j7200/ipc_echo_testb_mcu1_0_release_strip.xer5f with MCU1_0 MCAL binary. Make sure to keep to rename the binary to ipc_echo_testb_mcu1_0_release_strip.xer5f
    • Navigate to (SDK INSTALL DIR) and run make u-boot on the terminal.
    • Replace the tispl.bin file in the SD-card inside bootfs with tispl.bin at (SDK INSTALL DIR)/board-support/ti-u-boot-...../build/a72
    • Insert SD-card in the board, ensure that the board is in SD card boot mode and power it on.
    • Once the application core is booted, log in with username root and run "rpmsg_char_simple -r 0 -n 10" to view the communication logs.

To run the CddIpcRprocLinuxApp on mcu2_1

  1. Download and install the Linux installer
  2. Partition and flash the SD card using the below mentioned steps
  3. If using EdgeAI linux SDK wic image, In uEnv.txt file of boot partition, change from "name_overlays=k3-j721e-evm-virt-mac-client.dtbo k3-j721e-vision-apps.dtbo" to "name_overlays=k3-j721e-evm-virt-mac-client.dtbo"
  4. Navigate to ${SD_CARD_PATH}/rootfs/lib/firmware/ti-ipcs
    • Remove ipc_echo_test_mcu2_1_release_strip.xer5f and move the cdd_ipc_app_rc_linux_mcu2_1_release_strip.xer5f binary to $SD_CARD_PATH/rootfs/lib/firmware/pdk-ipc
    • Rename the cdd_ipc_app_rc_linux_mcu2_1_release_strip.xer5f file to ipc_echo_test_mcu2_1_release_strip.xer5f
    • Remove the old symbolic firmware link for mcu2_1 in $SD_CARD_PATH/rootfs/lib/firmware with rm j7200-main-r5f0_1-fw(for j7200) or rm j7-main-r5f0_1-fw(for j721e)
    • Recreate the symbolic link with the new firmware for J7200 by sudo ln -s ti-ipc/j7200/ipc_echo_test_mcu2_1_release_strip.xer5f j7200-main-r5f0_1-fw
    • Recreate the symbolic link with the new firmware for J721E by sudo ln -s ti-ipc/j721e/ipc_echo_test_mcu2_1_release_strip.xer5f j7-main-r5f0_1-fw
      • If user may have also relink below to ensure no overriding for J721e
      • Recreate the symbolic link with the new firmware for J721E by sudo ln -s ti-ipc/j721e/ipc_echo_test_mcu2_0_release_strip.xer5f j7-main-r5f0_1-fw
    • Once the application core is booted, log in with username root.
    • Run "rpmsg_char_simple -r 3 -n 10" and "modprobe rpmsg_client_sample count=10" command to view the communication logs. Please refer the SOC user manual for cdd_ipc_app.

Back To Top

Memory Mapping

Various objects of this implementation (e.g. variables, functions, constants) are defined under different sections. The linker command file at (Examples Linker File (Select memory location to hold example binary)) defines separate section for these objects. When the driver is integrated, it is expected that these sections are created and placed in appropriate memory locations. (Locations of these objects depend on the system design and performance needs)

Section CDD_IPC_CODE CDD_IPC_VAR CDD_IPC_VAR_NOINIT CDD_IPC_CONST CDD_IPC_CONFIG
CDD_IPC_DATA_NO_INIT_UNSPECIFIED_SECTION (.data) USED
CDD_IPC_DATA_INIT_32_SECTION USED
CDD_IPC_TEXT_SECTION USED
CDD_IPC_DATA_NO_INIT_8_SECTION USED
CDD_IPC_CONFIG_SECTION USED
CDD_IPC_ISR_TEXT_SECTION USED
CDD_IPC_CONFIG_SECTION USED

Back To Top

Dependencies on SW Modules

DET

This implementation depends on the DET in order to report development errors and can be turned OFF. Refer to the Development Error Reporting section for detailed error codes.

Back To Top

SchM

This implementation requires 1 level of exclusive access to guard critical sections. Invokes SchM_Enter_Cdd_Ipc_IPC_EXCLUSIVE_AREA_0(), SchM_Exit_Cdd_Ipc_IPC_EXCLUSIVE_AREA_0() to enter critical section and exit.

In the example implementation (SchM_Cdd_Ipc.c), all the interrupts on CPU are disabled. However, disabling of the enabled Mailbox related interrupts should suffice.

Back To Top

File Structure

Cdd Ipc File Structure

cdd_ipc_dir_src.png
CDD Ipc Implementation Directory Structure
  • Driver implemented by: Cdd_Ipc.c, Cdd_IpcIrq.c & Cdd_IpcPriv.h core driver files
  • Example Configuration by: Cdd_IpcCfg.c and Cdd_IpcCfg.h
  • Example Application by: CddIpcApp.c & CddIpcApp.h
  • Remote Core Application by: main_rtos.c, ipc_utils.c

Back To Top

Customizing Examples Application

Turn OFF Use Of Control End Point

IPC demo applications use atleast 2 applications running on 2 different cores. Namely ipc_remote_app & cdd_ipc_app OR cdd_ipc_profile_app , these two applications would have to be re built when this features requires to be turned OFF

  1. Update MCAL configuration
    1. Example Application
      1. The configuration used by this application is present in (SDK Install Directory)/mcusw/mcal_drv/mcal/examples_config/CddIpc_Demo_Cfg/output/generated/soc/(SOC)/mcu1_0
        • OR Incase application is being hosted on MCU 2 1 (SDK Install Directory)/mcusw/mcal_drv/mcal/examples_config/CddIpc_Demo_Cfg/output/generated/soc/(SOC)/mcu2_1
      2. The configuration used by this application in case of am62x is present in host R5F (SDK Install Directory)/mcusw/mcal_drv/mcal/examples_config/CddIpc_Demo_Cfg/output/generated/soc/am62x/mcu0_0
        1. The configuration used by this application in case of am62ax is present in host MCU R5FSS 0 0 (SDK Install Directory)/mcusw/mcal_drv/mcal/examples_config/CddIpc_Demo_Cfg/output/generated/soc/am62ax/mcu0_0
      3. The configuration used by this application in case of am62px is present in host MCU R5FSS 0 0 (SDK Install Directory)/mcusw/mcal_drv/mcal/examples_config/CddIpc_Demo_Cfg/output/generated/soc/am62px/mcu0_0
        1. Update the configurator to TURN OFF as show below
          cdd_ipc_ug_no_announce.png
          Announce API turned OFF
      4. Regenerate the configuration and copy the same into location specified above
      5. Alternately
        1. Set the macro CDD_IPC_ANNOUNCE_API to STD_OFF in Cdd_IpcCfg.h
        2. Re compile the MCAL demo application User Guide
    2. Profiling Application
      1. Update Remote Application configuration

Back To Top

Error Handling

Development Error Reporting

Development errors are reported to the DET using the service Det_ReportError(), when enabled. The driver interface files (Cdd_IpcCfg.h shown in the driver directory structure of the File Structure section)

Refer Design Document for detailed [Error Codes] (Refer to Design Document provided in CSP)

Back To Top

Error codes

Production error are reported to DET via Det_ReportError(). Only the error codes in the Cdd Ipc driver specifications are reported which are listed in [] (Refer to Design Document provided in CSP) Back To Top

API Description

The AUTOSAR BSW Eth Driver specification details the APIs [[2] (Refer to Design Document provided in CSP)]

Back To Top

Example Application

Flow Chart

The flow chart below depicts the demo application

  • ipc_remote_app_mpu1_0_release.xa53fg would be hosted on Remote Core (MPU 1 0)
  • cdd_ipc_app_mcu1_0_release.xer5f would be hosted on Local Core (MCU 1 0)
  • ipc_rpmsg_echo.release.out would be hosted on Remote Core (M4)
  • cdd_ipc_app_mcu0_0_release.xer5f would be hosted on Local Core (R5F)
demo_cdd_ipc_flowchart.png
Cdd Ipc Demo Application flow chart

Back To Top

Example Logs

MCU 1 0 Linux communication

    rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.11: new channel: 0x400 -> 0xb!
    rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.11: incoming msg 1 (src: 0xb)
    rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.11: incoming msg 2 (src: 0xb)
    rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.11: incoming msg 3 (src: 0xb)
    rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.11: incoming msg 4 (src: 0xb)
    rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.11: incoming msg 5 (src: 0xb)
    rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.11: incoming msg 6 (src: 0xb)
    rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.11: incoming msg 7 (src: 0xb)
    rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.11: incoming msg 8 (src: 0xb)
    rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.11: incoming msg 9 (src: 0xb)
    rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.11: incoming msg 10 (src: 0xb)
    rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.11: goodbye!

MCU 2 1 Linux communication

    rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.11: new channel: 0x400 -> 0xb!
    rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.11: incoming msg 1 (src: 0xb)
    rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.11: incoming msg 2 (src: 0xb)
    rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.11: incoming msg 3 (src: 0xb)
    rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.11: incoming msg 4 (src: 0xb)
    rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.11: incoming msg 5 (src: 0xb)
    rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.11: incoming msg 6 (src: 0xb)
    rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.11: incoming msg 7 (src: 0xb)
    rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.11: incoming msg 8 (src: 0xb)
    rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.11: incoming msg 9 (src: 0xb)
    rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.11: incoming msg 10 (src: 0xb)
    rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.11: goodbye!

MCU 2 1

    CDD_IPC_APP : CDD IPC MCAL Version Info
    CDD_IPC_APP :---------------------
    CDD_IPC_APP : Vendor ID           : 44
    CDD_IPC_APP : Module ID           : 255
    CDD_IPC_APP : SW Major Version    : 1
    CDD_IPC_APP : SW Minor Version    : 0
    CDD_IPC_APP : SW Patch Version    : 0

    CDD_IPC_APP :
    CDD_IPC_APP : Sample Application - STARTS !!!
    CDD_IPC_APP : Received ti.ipc4.ping-pong as ctrl MSG from MCU 1 1
    CDD_IPC_APP : Received ping 0 Iteration 10 from MCU 1 1
    CDD_IPC_APP : Received ping 1 Iteration 9 from MCU 1 1
    CDD_IPC_APP : Received ping 2 Iteration 8 from MCU 1 1
    CDD_IPC_APP : Received ping 3 Iteration 7 from MCU 1 1
    CDD_IPC_APP : Received ping 4 Iteration 6 from MCU 1 1
    CDD_IPC_APP : Received ping 5 Iteration 5 from MCU 1 1
    CDD_IPC_APP : Received ping 6 Iteration 4 from MCU 1 1
    CDD_IPC_APP : Received ping 7 Iteration 3 from MCU 1 1
    CDD_IPC_APP : Received ping 8 Iteration 2 from MCU 1 1
    CDD_IPC_APP : Received ping 9 Iteration 1 from MCU 1 1
    CDD_IPC_APP : Received ti.ipc4.ping-pong as ctrl MSG from MCU 2 0
    CDD_IPC_APP : Received ping 0 Iteration 10 from MCU 2 0
    CDD_IPC_APP : Received ping 1 Iteration 9 from MCU 2 0
    CDD_IPC_APP : Received ping 2 Iteration 8 from MCU 2 0
    CDD_IPC_APP : Received ping 3 Iteration 7 from MCU 2 0
    CDD_IPC_APP : Received ping 4 Iteration 6 from MCU 2 0
    CDD_IPC_APP : Received ping 5 Iteration 5 from MCU 2 0
    CDD_IPC_APP : Received ping 6 Iteration 4 from MCU 2 0
    CDD_IPC_APP : Received ping 7 Iteration 3 from MCU 2 0
    CDD_IPC_APP : Received ping 8 Iteration 2 from MCU 2 0
    CDD_IPC_APP : Received ping 9 Iteration 1 from MCU 2 0
    CDD_IPC_APP : Received ti.ipc4.ping-pong as ctrl MSG from MPU 1 0
    CDD_IPC_APP : Received ping 0 Iteration 10 from MPU 1 0
    CDD_IPC_APP : Received ping 1 Iteration 9 from MPU 1 0
    CDD_IPC_APP : Received ping 2 Iteration 8 from MPU 1 0
    CDD_IPC_APP : Received ping 3 Iteration 7 from MPU 1 0
    CDD_IPC_APP : Received ping 4 Iteration 6 from MPU 1 0
    CDD_IPC_APP : Received ping 5 Iteration 5 from MPU 1 0
    CDD_IPC_APP : Received ping 6 Iteration 4 from MPU 1 0
    CDD_IPC_APP : Received ping 7 Iteration 3 from MPU 1 0
    CDD_IPC_APP : Received ping 8 Iteration 2 from MPU 1 0
    CDD_IPC_APP : Received ping 9 Iteration 1 from MPU 1 0
    CDD_IPC_APP : Transmitted and Received 10 times
    CDD_IPC_APP : Sample Application - Completes !!!

Back To Top

References

Sl No Specification Comment / Link
1 AUTOSAR 4.3.1 AUTOSAR Specification for CDD Driver & Integration Intranet Link

Back To Top