SoC to Microcontroller Communications

NVIDIA Camera Control Protocol

Since the Microcontroller Unit (MCU) has access to the Camera Interface Module (CIM), the MCU controls camera power and multiplex camera control between different devices. NVIDIA Camera Control Protocol (NVCCP) is used to send camera control commands from SoC to the MCU and receive acknowledgement back. The communication is conducted over ethernet.
Consult the Operating System Release Notes before making any changes to the default configuration of the platform.
For the DRIVE AGX platform, Camera Control Protocol (NVCCP) is implemented using the generic shared user-space library ( the NVCCP user-space daemon (nvccp_daemon).
All camera applications intending to use NVCCP shall link to the NVCCP user space library. The library layer exports a set of APIs which the camera applications shall use.
A screenshot of a cell phone Description automatically generatedThe NVCCP user-space daemon runs on the Xavier in the same partition as the camera application. The daemon waits for NVCCP messages from the camera application that is linking to the NVCCP user library. Any message received at the daemon is forwarded to the MCU and the response is received from the MCU. This response is then sent back to the camera application. The NVCCP daemon also auto releases ownership of a camera group if the camera application using that camera group crashes or exits. The daemon is launched at startup. The following diagram explains the communication flow.

Camera Control Protocol

The NVIDIA Camera Control Protocol is used to control the states of the Cameras and Camera Aggregators/De-Serializers from Xavier A, Xavier B, and Xavier CVM by communicating with the MCU. It is an application level protocol which carries the camera and aggregator states. It has been designed to handle multiple captures from multiple SoCs. It satisfies these requirements:
1. Frame Sync Control
All use cases enforce Xavier A to be booted and generating Frame Sync.
Xavier A is ALWAYS chosen as Frame Sync source at MCUboot.
All four FRSYNC buffers are to be enabled by default at MCUboot.
2. Camera Group Ownership
Any camera application MUST request a camera group ownership using request_ownership() API before power control and release the ownership using release_ownership()API at application exit.
Each Xavier can capture independently as primary if they capture on camera groups exclusive to each other.
A camera group can ONLY have one primary and one secondary for dual Xavier capture.
For all dual Xavier cases, Xavier A is ALWAYS the Primary and Xavier B is ALWAYS the secondary.
3. Power Control
Each Xavier MUST register itself as primary or secondary using request_ownership()API before using the power control APIs.
Only Primary can hardware power ON the deserializer/cameras. Secondary cannot issue power ON before Primary.
Either Primary or Secondary can hardware power OFF based on the exit sequence.
These requirements are implemented in the form of state machines in the MCU Firmware. There is a state machine associated with each camera unit and a state machine for each camera aggregator. Therefore, each camera group has five state machines associated with it.
The state for any camera is as follows.
Execution of each command on MCU returns a Status message to the invoking Tegra providing information about the execution.
The Transitions denote the commands generated from Primary or Secondary and the returned Status.
For either Tegra to execute commands in the state machine, the Tegra must register itself by requesting ownership of the camera group as Primary or secondary.
The logic flow for this process is as follows.

Library Usage and Configuration

The NvCCP communication with MCU is supported only over a VLAN ethernet interface and this VLAN interface is established at initialization.
The configuration file tacp.cfg is provided along with the sample application to use the NvCCP library.
Refer to the Configuration for NvCCP and Common Interface section for detailed information on the configuration parameters and VLAN interface creation.
The communication between the NVCCP user-space library and the NVCCP daemon happens using TCP protocol.
Following are the port numbers used for communication between the NVCCP user-space library and the NVCCP daemon. These are fixed and cannot be changed by configuration.
Daemon Endpoint:
IP Address
Client Endpoints
The Client has multiple TCP endpoints. These endpoints are based on the camera group/ownership combination. These ports are defined as follows:
Camera Group
IP Address
The Client also has a pool of generic endpoints that are used for NVCCP API not related to camera group ownership as follows:
IP Address

Supported APIs

The file ccp.h provides the APIs for various commands and camera structures. There are four camera groups in Xavier enumerated as A, B, C, and D. Each camera group has an associated aggregator which must be turned on before a camera can be powered on. Each camera group also has four individual camera units enumerated from 1 to 16.
Camera Group Id ENUM
typedef enum {
} nvccp_cam_group_id;
Camera Unit Id ENUM
typedef enum{
/* Camera group A */
NVCCP_CAM_A0 = 0x01,
NVCCP_CAM_A1 = 0x02,
NVCCP_CAM_A2 = 0x04,
NVCCP_CAM_A3 = 0x08,
/* Camera group B */
NVCCP_CAM_B0 = 0x10,
NVCCP_CAM_B1 = 0x20,
NVCCP_CAM_B2 = 0x40,
NVCCP_CAM_B3 = 0x80,
/* Camera group C */
NVCCP_CAM_C0 = 0x0100,
NVCCP_CAM_C1 = 0x0200,
NVCCP_CAM_C2 = 0x0400,
NVCCP_CAM_C3 = 0x0800,
/* Camera group D */
NVCCP_CAM_D0 = 0x1000,
NVCCP_CAM_D1 = 0x2000,
NVCCP_CAM_D2 = 0x4000,
NVCCP_CAM_D3 = 0x8000
} nvccp_cam_id;
NVCCP Command Status ENUM
typedef enum {
} nvccp_return_t;
Camera Ownership Mode ENUM
typedef enum {
} nvccp_cam_mode;
Tegra Id ENUM
typedef enum {
} nvccp_tegra_id;
NVCCP command APIs
nvccp_return_t nvccp_request_ownership(nvccp_cam_group_id cam_group,nvccp_cam_mode cam_master);
nvccp_return_t nvccp_release_ownership(nvccp_cam_group_id cam_group,nvccp_cam_mode cam_master);
nvccp_return_t nvccp_set_cam_pwr_on(nvccp_cam_group_id cam_group);
nvccp_return_t nvccp_set_cam_pwr_off(nvccp_cam_group_id cam_group);
nvccp_return_t nvccp_set_cam_unit_pwr_on(nvccp_cam_id cam_id);
nvccp_return_t nvccp_set_cam_unit_pwr_off(nvccp_cam_id cam_id);
nvccp_return_t nvccp_set_aggreg_pwr_on(nvccp_cam_group_id cam_group);
nvccp_return_t nvccp_set_aggreg_pwr_off(nvccp_cam_group_id cam_group);
nvccp_return_t nvccp_set_frsync_owner(nvccp_tegra_id tegra_id);
nvccp_return_t nvccp_set_frsync_enable(nvccp_cam_group_id cam_group);
nvccp_return_t nvccp_set_frsync_disable(nvccp_cam_group_id cam_group);
nvccp_return_t nvccp_get_cam_unit_pwr_status(uint16_t *cam_id);
nvccp_return_t nvccp_get_aggreg_pwr_status(uint8_t *cam_group);
nvccp_return_t nvccp_get_frsync_enable_status(uint8_t *cam_group);

CCP Sample Application Usage

The ccp_test_app can be used to test the NVCCP functionality. It provides a command line interface to execute each of the NVCCP commands from the SoC. When the application requests for a group ownership, it will retain the ownership of the camera group until it explicitly releases the ownership or the application dies. This can be exercised by the "wait" argument to the ccp_test_app application while requesting ownership. If the application dies or the "nowait" option is used, the camera group ownership will be automatically released by the NVCCP daemon when the cpp_test_app application exits. 
Command Usage
./ccp_test_app req_ownership m/master/s/slave a/b/c/d wait/nowait
./ccp_test_app rel_ownership m/master/s/slave a/b/c/d
./ccp_test_app set_cam_agg_pwr_on a/b/c/d
./ccp_test_app set_cam_agg_pwr_off a/b/c/d
./ccp_test_app set_cam_pwr_on a/b/c/d
./ccp_test_app set_cam_pwr_off a/b/c/d
./ccp_test_app set_cam_unit_pwr_on 0-15
./ccp_test_app set_cam_unit_pwr_off 0-15
./ccp_test_app set_cam_fsync_en a/b/c/d
./ccp_test_app set_cam_fsync_dis a/b/c/d
./ccp_test_app set_cam_fsync_owner ta/tb
./ccp_test_app get_cam_unit_pwr_status
./ccp_test_app get_cam_agg_pwr_status
./ccp_test_app multithread_test <no of threads>

Use Cases

Single SoC Capture Use case
Dual SoC Capture Use case

Common Interface for Soc to MCU communication

MCU manages Power-On, Power-Off, Recovery, Reset sequence of SoC on DRIVE AGX board. It supports re-flashing its firmware and its configuration, and GPIO based boot chain selection of SoC firmware.
User application on SoC such as Driver Update communicate with MCU to harvest these features of MCU. This communication is established through Common Interface which exposes set of interfaces on SoC and connects to MCU using UDP over ethernet.
Common Interface offers below features:
Set and get Hyperion configuration from MCU firmware
Enable, disable, and get current state of L3SS from MCU firmware
Read InfoROM dump
Set Bootstrap
Get current version information of MCU firmware
Validate MCU firmware to be flashed for compatibility
Flash program Update and Production MCU firmware
Set GPIO based Boot chain configuration
Read current configuration of GPIO based Boot chain configuration
SoC reboot and MCU reboot
The diagram below provides positioning of Common Interface modules in the system:

Library Usage and Configuration

User applications intending to use these functionalities shall link to Common Interface Library (
Availability of these features are build configuration dependent. All features are available on the standard build. Boot Chain APIs are available in safety builds only.
The Common Interface communication with MCU is only supported over a VLAN ethernet interface; the VLAN interface is established at initialization.
Refer to the Configuration for NvCCP and Common Interface section for detailed information on the configuration parameters and VLAN interface creation.

Common Interface Sample Application Usage

The common_if_testapp is a command line interface to verify supported features. Executing “common_if_testapp -h“ lists supported commands with briefs description.
Examples of command with short description:
Resets MCU. Reset the complete DRIVE AGX board
#common_if_testapp -mcureset
Reset Tegra x1
#common_if_testapp -tegrareset x1
Sets default boot chain of Tegra x1 to A
#common_if_testapp -set_default_bootchain x1 A
Makes Tegra x1 to boot from non default boot chain on next boot
#common_if_testapp -set_next_bootchain x1 Alternate
Gets the default boot chain for Tegra of x1
#common_if_testapp -get_default_bootchain x1
Gets active/current boot chain for Tegra x1
#common_if_testapp -get_active_bootchain x1
Flashes given production firmware
#common_if_testapp -flash_mcu_fw lib/firmware/DRIVE-V5.2.3-E3550-AFW-Aurix-With3LSS-StepA-4.03.01.hex
Flashes given update firmware
#common_if_testapp -flash_mcu_ufw lib/firmware/DRIVE-V5.2.x-E3550-NV-Aurix-UPDATE-StepA-1.29.16.hex
Reads currently running firmware version
#common_if_testapp -get_fw_version
Reads update firmware version flashed on MCU
#common_if_testapp -get_update_fw_version
Reads the version of the hexfile from its content
#common_if_testapp -get_mcu_hexfile_version lib/firmware/DRIVE-V5.2.x-E3550-NV-Aurix-UPDATE-StepA-1.29.16.hex
Reads data from infoROM dump
#common_if_testapp -get_inforom_dump
Sets Tegra x1 boot strap medium to QSPI
#common_if_testapp -set_bootstrap x1 qspi
Enable Safety Services on MCU.
#common_if_testapp -safety_services enable
Gets current Hyperion Configuration on MCU
#common_if_testapp -hyperion_cfg getStatus
Reboot MCU in Production FW mode
#common_if_testapp -reboot_mcu_afw
Reboot MCU in Update-FW mode
#common_if_testapp -reboot_mcu_ufw

Programming Sequence

Flowchart for production firmware flash programming
Flowchart for update firmware flash programming

Configuration for NvCCP and Common Interface

The configuration parameters required by NvCCP and Common Interface are in the configuration file provided in the root file system at:
The configuration file contains these parameters:
AURIX_IP_ADDRESS=<ip address>
AURIX_SERVER_PORT=<server port> (Used by NvCCP)
AURIX_BOOTCHAIN_PORT=<server port> (Used by Common Interface)
AURIX_IP_ADDRESS is the IP Address of the MCU.
AURIX_SERVER_PORT is the ethernet port on which NVCCP communicates with the MCU.
AURIX_BOOTCHAIN_PORT is the ethernet port on which Common Interface communicates with the MCU.
CLIENT_DAEMON_TIMEOUT_S is the timeout in seconds by which the NVCCP user-space library expects a response from AURIX.
Parameters applicable for NvCCP and their default values are listed below:
Parameters applicable for Common Interface and their default values are listed below:
For more information on how VLAN interface is established and its configuration details, see Ethernet 100M/1G Networking.
For the ethernet interface to be successfully established, AURIX address in the configuration file must match the IP address stored in AURIX. Refer to the MCU Porting Guide for IP and port configuration on MCU.