AD-96TOF1-EBZ with Nvidia Jetson Xavier NX : Regarding aditof-demo app crash and recorded data processing

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

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.

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?

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.  

Hi,
We flashed the Raspberry PI image for AD-FXTOF1-EBZ and we are able to see the depth and IR data using aditof-demo app. Please find the image attached below;

We also flashed the Jetson-Nano image for AD-FXTOF1-EBZ but we are getting the following error in Jetson Nano. Please find the image attached below:

We flashed the image for  AD-96TOF1-EBZ in both Raspberry PI and Jetson Nano. But in that also we are getting the same error as mentioned above. 

 

Could you please help us on this issue?

How are you powering the AD-FXTOF1-EBZ - from a USB port or an external 5V supply? It needs a supply capable of delivering 2A.

Can you make sure the flex cable you are using is still fine and properly inserted in the connectors?

hi,

We have dumped the thre firmware for three modes.

configured i2c -> write all power on registers with value -> write all registers with the value from near mode dump > changed mode to depth only by 

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

But we are not getting the data properly.

we want to make the output depth only. Please share the registers for changing to depth only mode ?

The depth only mode is set by writing 0x03 in register 0xc3da, so what you did is correct, but the size of the arrays should be 6, not 5.

Register 0xc3dc controls the mipi virtual channel setting and it should not be written unless you want a different setting for the virtual channels IDs.

Hi Analog team,

we tried to read eeprom data from AD-FXTOF1-EBZ EVB on raspberry pi and also jetson nano, but we are getting the following error. can you please help us on this?