SoC to Microcontroller Communications
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 (CCP) is implemented using the generic shared library The library layer exports a set of APIs to communicate with the remote MCU. Consequently, applications must include this library and must send commands using the exported APIs to interact with the remote MCU.
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 Master if they capture on camera groups exclusive to each other.
A camera group can ONLY have one Master and one slave for dual Xavier capture.
For all dual Xavier cases, Xavier A is ALWAYS the Master and Xavier B is ALWAYS the slave.
3. Power Control
Each Xavier MUST register itself as Master or Slave using request_ownership()API before using the power control APIs.
Only Master can hardware power ON the deserializer/cameras. Slave cannot issue power ON before Master.
Either Master or Slave 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 Master or Slave 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 Master or slave.
The logic flow for this process is as follows.
Library Usage and Configuration
The default configuration files are provided in the root file system at:
This configuration file is used by to obtain the required values such as:
Remote MCU IP
Tegra IP
Receive timeout values
Model and interface information.
The configuration file supports these parameters:
AURIX_IP_ADDRESS=<ip address>
TEGRA_A_IP_ADDRESS=<ip address>
TEGRA_B_IP_ADDRESS=<ip address>
TEGRA_IP_ADDRESS=<ip address>
AURIX_SERVER_PORT=<server port>
<interface> must be VLAN interface eth0.200.
All SoC-MCU communication moved from virtual Ethernet interface to fixed VLAN based interface; therefore, the <interface> value is fixed to eth0.200 and is not configurable.
In the case of the Ethernet interface, the required parameters are:
In the case of the ethernet interface, these parameters are used for automatic IP assignment by nv_tacp_init service while booting.
CCP ethernet interface communication is supported on AURIX_SERVER_PORT 5000 only.
For CCP ethernet interface, AURIX and SoC IP address in the configuration file must match the IP address stored in AURIX.
Example of tacp.cfg:
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;
CCP 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 Aurix 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