Post Go back to editing

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

Hi Analog Team,

We have successfully flashed the Nvidia Jetson Xavier NX SD card release image using Etcher and we are also able to build the aditof-demo app( Note: Done git pull before building demo app). We can see both Depth and IR view in live mode through the HDMI display. 

But we are getting an app crash while playing the recorded file. Please find the attached snapshot of the error.

We could find the recorded data file in the Xavier home directory and tried to view the same using the vooya application in Linux. 
But the quality is not as expected while comparing with the live view through the HDMI display. 
  1. Is there any post-processing methods used in the aditof-demo app for getting better quality in the UI? 
  2. Is any fix available for the app crash mentioned above?

Inserted recorded data
[edited by: sree_devi at 4:07 AM (GMT -4) on 31 Aug 2021]
  • 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  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:

    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?

Reply Children