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

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.

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.