1 . We have tried to pull the latest commit in master branch for the fix for app crash while recording and playback using aditof demo. But we are getting the following error 2.

2. Again we have tried to check out the default branch HEAD at v2.0.0 and we could successfully able to run aditof demo. Then tried to run first frame. Please see the attached log. All values are zero. first_frame_log.txt

Hello, 

Please verify if the latest commit from the master branch on the board is the same as the one from github and if there were any conflicts when using git pull on the master branch. We are trying to reproduce the error.

Hi,

1. What is the purpose of EEPROM there in EVB ? only to store the calibration data and is this only one-time flashable? 

2. Is there any software technical documents there for AD-96TOF1-EBZ to understand the configuration needed. We would like to interface the EVB with another platform , it would be helpful if we get the documents along with consolidated register details with values 

1. It holds calibration data and 3 firmwares for each mode (near, medium, far).

2.This is the lading page for the evaluation board:

https://wiki.analog.com/resources/eval/user-guides/ad-96tof1-ebz

This is EEPROM map:

github.com/.../eeprom_register_map.md

if we disconnected eeprom from evb using the switch available, shall we get data over MIPI ?

Only if you do some modifications to the SDK. This is because the SDK reads the EEPROM right after engaging with the camera. Then reads calibration information that will user later to adjust/correct depth information in the frame. It also reads the 3 firmwares from which uses one to program the camera.

Once the camera is programmed, it does not need the EEPROM anymore.

Thanks for the reply.

1. If we want to work only with one particular mode let's say example far mode, then we need to flash with the required firmware from EEPROM and we can disconnect the same right?

2. It would be helpful if you could elaborate more about the flow of EEPROM and addi9036 communication flow as a single i2c bus is connecting in between Xavier,aadi9036, temp sensor,EEPROM. Who will be the master in the case of EEPROM and addi9036 communication? 

3. Is this the eeprom binary https://github.com/analogdevicesinc/aditof_sdk/blob/master/misc/ad-96tof1-ebz/ad96tof1_eeprom.bin  which holds the firmware for all three modes?
 

1. Yes, that is correct

2. The master on the I2C bus is the CPU. The CPU reads the eeprom and the tempreature sensor and programs the addi9036 with the firmware from the eeprom

3. Yes, that binary file holds the firmware for all the 3 modes

1. As a conclusion, the EEPROM is flashed from Xavier using the .bin file mentioned earlier so that EEPROM will have the firmware for three modes. As per the user selection of modes from UI like aditof-demo, the Xavier will read the corresponding setting from EEPROM and will program the addi9036 and the camera will be calibrated for the selected mode. After this, if there is no change in mode settings we can disconnect the EEPROM. Is this correct? Programming of ADDI9036 means that the data from EEPROM is writing into some registers in addi9036?

2. We are trying to interface AD-96TOF1-EBZ EVB with Qualcomm 610 which is having a different approach for camera integration. There we use some XML files for configuring the camera from userspace. The kernel and drivers are Qualcomm property. Let us know if you have done the integration of the EVB with Qualcomm chipset qcs610 or with the related chipsets like qcs605,qcs410..etc.If done please share your input here.

1. After the addi9036 is programmed the EEPROM is not accessed anymore. Programming means writing addi9036 registers using the data in the EEPROM.

2. Unfortunately we haven't done any porting to Qualcomm processors. But the assumption is that the addi9036 v4l2 Linux driver should work either as is or can be used as starting point to incorporate any changes required by the Qualcomm proprietary camera system.

1. After the addi9036 is programmed the EEPROM is not accessed anymore. Programming means writing addi9036 registers using the data in the EEPROM.

2. Unfortunately we haven't done any porting to Qualcomm processors. But the assumption is that the addi9036 v4l2 Linux driver should work either as is or can be used as starting point to incorporate any changes required by the Qualcomm proprietary camera system.

Thank you for the valuable input.

1. We could find one driver file in location aditof_sdk/misc/nvidia/jetson/kernel_src/kernel/kernel-4.9/drivers/media/i2c/addi9036.c. Is this common for all jetson platform for nano, xavier nx/agx .etc ?

2. We are trying to integrate the EVB to QCS610 by eliminating the use of EEPROM.

From aditof-SDK we could able to find function  "aditof::Status Camera96Tof1::setMode" from file aditof_sdk/sdk/src/cameras/ad-96tof1-ebz/camera_96tof1.cpp is setting the AFE registers with values that is read from EEPROM (firmware according to the mode) and after that writing register set for VC ID with following values for both depth and IR.

afeRegsAddr[5] = {0x4001, 0x7c22, 0xc3dc, 0x4001, 0x7c22};
afeRegsVal[5] = {0x0006, 0x0004, 0xe4, 0x0007, 0x0004};

Also the above mentioned driver is using the following registers for powering up and power down

addi9036_power_up[] = {
{ 0xc4c0, 0x001c },
{ 0xc4c3, 0x001c },
{ 0xc4d7, 0x0000 },
{ 0xc4d5, 0x0002 },
{ 0xc4da, 0x0001 },
{ 0xc4f0, 0x0000 },
{ 0xc427, 0x0003 },
{ 0xc427, 0x0001 },
{ 0xc427, 0x0000 },
{ 0xc426, 0x0030 },
{ 0xc426, 0x0010 },
{ 0xc426, 0x0000 },
{ 0xc423, 0x0080 },
{ 0xc431, 0x0080 },
{ 0x4001, 0x0007 },
{ 0x7c22, 0x0004 }
};

addi9036_power_down[] = {
{ 0xc022, 0x0001 },
{ 0x4001, 0x0006 },
{ 0x7c22, 0x0004 },
{ 0xc431, 0x0082 },
{ 0xc423, 0x0000 },
{ 0xc426, 0x0020 },
{ 0xc427, 0x0002 },
{ 0xc4c0, 0x003c },
{ 0xc4c3, 0x003c },
{ 0xc4d5, 0x0003 },
{ 0xc4da, 0x0000 },
{ 0xc4d7, 0x0001 },
{ 0xc4f0, 0x0001 }
};

powering up reg with values -> firmware from EEPROM(AFE registers and values) -> Register set for VC ID

Are these the involved registers for bringing up the camera to work in a specific mode? Have we missed any setting here? It would be helpful if you could share the registers and values in each firmware so that we can eliminate EEPROM usage.

1. Yes, that driver is common for all the NVIDIA platforms.

2. Writing the firmware into the addi9036 for a certain mode is done here: https://github.com/analogdevicesinc/aditof_sdk/blob/master/sdk/src/cameras/ad-96tof1-ebz/camera_96tof1.cpp#L292

The easiest way to get all the register writes for a mode is to save the contents of the "firmwareData" vector into a file. This vector contains consecutive register [address, value] pairs.

The power up and power down register settings are correct and should be used in addition to the register settings that are done for a certain mode.

The other register writes you mentioned are useful only if setting the output of the addi9036 to ir only / depth only and changing the VC IDs. By default addi9036 is configured to output both depth and ir, both on VC 0.

Hi,

We need some details like sensorIdRegAddr and sensoid for integrating in to Qualcomm architecture which we couldn't find the same in the "CCD TOF Signal Processor with Programmable Timing and V-Driver ADDI9036" datasheet. Could you please provide the documents having these details?

The ADDI9036 does not have an ID register. A workaround would be read any other register and compare the reading to the register's default value since the reading is done only once before the addi9036 is programmed. 

shall we use 0xc100 reg with default value 0x11?

0xc00  should be fine, but the default value is 0x0001

Hi,

We have seen the kernel configurations from file https://github.com/analogdevicesinc/aditof_sdk/blob/master/misc/nvidia/xaviernx/kernel_src/hardware/nvidia/platform/t19x/common/kernel-dts/t19x-common-modules/tegra194-camera-addi9036.dtsi

Here the addi9036 is mentioned as 

The output of addi9036 is yuv422 right ?

ADDI9036 output format is RAW12, which is equivalent to 12bit Bayer.

1 .We are getting an error like "failed to get the frame" even after the device is connected to Xavier nx ( from dmesg).



Have you faced any such issues before?

2. What are all the lines in between evb and xaviernx? only MIPI2 lane and I2C sda &scl  ?
We have seen in linux addi9036 driver, GPIO0 is setting value to 0 in addi9036_power_on function ?   

From the logs you posted it can be seen that the addi9036 and the eeprom are not responding on i2c, which might mean that the selected i2c port might not be right or there is a problem with the flex cable connection.

Only the mipi and i2c interfaces are used, the GPIOs are not connected.