Post Go back to editing

Eeprom data corrupted?

Hi,

I have problem with the AD-96TOF1-EBZ eeprom.
I have installed your sdk on a raspberry pi.
I run the aditof-demo example and it gives me the following error :

Camera range for mode: near is: 250mm and 800 mm
Failed to read firmware eeprom 
terminate called after throwing an instance of ‘std::bad_array_ne_length’
	what(): std::bad_array_new_length
Aborted

Is my eeprom data corrupted?
If it is the case how to fix it?

Thanks.

Parents
  • Hi, thank you for your answer,

    I have a rev. C.
    I did the changes that must be made on the camera board: switch S1 to 1 and for S5 only 1 to OFF.
    I did the power on sequence steps too.

    I have the following log now : 

    pi@raspberrypi:~/Desktop $ ./aditof-demo.sh
    I0505 22:13:47.918064 804 device_enumerator_raspberry.cpp:47] Looking for devices on the target
    I0505 22:13:47.921128 804 device_enumerator_raspberry.cpp:80] Looking at: /dev/video0 for an eligible TOF camera
    I0505 22:13:47.922816 804 system_impl.cpp:62] System initialized
    I0505 22:13:47.922966 804 camera_96tof1.cpp:78] Initializing camera
    I0505 22:13:47.923008 804 local_device.cpp:158] Opening device
    I0505 22:13:48.700927 804 calibration.cpp:261] EEPROM calibration data size 64940 bytes
    I0505 22:13:54.495831 804 camera_96tof1.cpp:95] Camera initialized
    I0505 22:13:54.500403 804 local_device.cpp:253] Starting device
    I0505 22:13:54.586835 804 camera_96tof1.cpp:129] Chosen mode: near
    I0505 22:13:54.586958 804 camera_96tof1.cpp:170] Camera range for mode: near is: 250 mm and 800 mm
    I0505 22:13:54.588925 804 camera_96tof1.cpp:180] Found firmware for mode: near
    I0505 22:13:54.588973 804 camera_96tof1.cpp:183] Firmware size: 10440 bytes
    I0505 22:13:55.875015 804 camera_96tof1.cpp:199] Camera calibration parameters for mode: near are gain: 1 offset: 0
    W0505 22:14:04.854745 808 local_device.cpp:830] select timeout
    W0505 22:14:04.855360 808 camera_96tof1.cpp:329] Failed to get frame from device

    It is the same result I obtained using a jetson nano (I wrote the issue last week here : ://github.com/analogdevicesinc/aditof_sdk/issues/337)

  • The changes that you made to the board seem fine, there isn't anything else that needs to be done

    The "select timeout" message shows there isn't any data coming from the camera. Do the 3 green LEDs on the top right corner of the camera board light up after you start the software?

    Have you tried using the camera with a DragonBoard? That would help identify if there's an issue with the camera or there's something wrong with the connection to the RPi or the Jetson boards. 

  • Do the 3 green LEDs on the top right corner of the camera board light up after you start the software?

    Yes it does.

    Have you tried using the camera with a DragonBoard?

    No but on a Jetson Nano.
    I have the same log than on Raspberry Pi.
    It seams that the select method always return 0 (timeout).

  • If the 3 LEDs turn on it means that the camera is programmed correctly. There might be a few things that could cause this issue:

     - the ribbon cable use to connect the camera is broken

     - the ToF camera might be damaged - could you please check visually the board to see if there's anything suspicious - broken components, any damage to the PBCs?

     - the ToF camera power supply could be faulty and it cannot withstand the current needed by the lasers

    Are you using the SDK from the master branch or did you get one of the releases? As a last resort, if you're using the master branch, I'd suggest trying with the latest release.

  • Thank you very much for your reply.

    - For the ribbon : I have tested it with a raspberry camera and it works

    - There is nothing suspicious on the board : no scratch, no impacts on the PCB and components

    - For the power supply : I have replaced it with another that I often use and the result is the same. 

    - On jetson I use master branch, on the raspberry I use this sdk image camo.githubusercontent.com/.../68747470733a2f2f696d672e736869656c64732e696f2f62616467652f72656c656173652d6c61746573745f73645f636172645f696d6167652d626c75652e737667

    I can't use the latest release (v1.3.0) on jetson (no jetson folder in sdk/src/target).

    Any other ideas?

  • Thank you for your reply.

    - For the ribbon : I have tested it with a raspberry camera and it works

    - There is nothing suspicious on the board : no scratch, no impacts on the PCB and components
    - For the power supply : I have replaced it with another that I often use and the result is the same. 

    - On jetson I use master branch. I can't use the latest release (v1.3.0) because there is no jetson folder in sdk/src/target.


      On the raspberry I use the latest release image
      I have just try with the v1.3.0 branch, it is almost the same log :

    pi@raspberrypi:~/Desktop $ ./aditof-demo.sh
    I0507 17:19:03.336621 3655 device_enumerator_raspberry.cpp:47] Looking for devices on the target
    I0507 17:19:03.338390 3655 device_enumerator_raspberry.cpp:80] Looking at: /dev/video0 for an eligible TOF camera
    I0507 17:19:03.340169 3655 system_impl.cpp:62] System initialized
    I0507 17:19:03.340320 3655 camera_96tof1.cpp:78] Initializing camera
    I0507 17:19:03.340359 3655 local_device.cpp:156] Opening device
    I0507 17:19:04.120066 3655 calibration_96tof1.cpp:163] EEPROM calibration data size 64940 bytes
    I0507 17:19:09.914160 3655 camera_96tof1.cpp:95] Camera initialized
    I0507 17:19:09.920964 3655 local_device.cpp:251] Starting device
    I0507 17:19:09.992377 3655 camera_96tof1.cpp:129] Chosen mode: near
    I0507 17:19:09.992539 3655 camera_96tof1.cpp:170] Camera range for mode: near is: 250 mm and 800 mm
    I0507 17:19:09.994480 3655 camera_96tof1.cpp:180] Found firmware for mode: near
    I0507 17:19:09.994532 3655 camera_96tof1.cpp:183] Firmware size: 10440 bytes
    I0507 17:19:11.280812 3655 calibration_96tof1.cpp:376] Camera calibration parameters for mode: near are gain: 1 offset: 0
    I0507 17:19:11.281221 3655 calibration_96tof1.cpp:388] Camera intrinsic parameters:
    fx: 391.248
    fy: 387.814
    cx: 325.193
    cy: 242.345
    W0507 17:19:16.949777 3662 local_device.cpp:863] select timeout
    W0507 17:19:16.950568 3662 camera_96tof1.cpp:316] Failed to get frame from device

    Any other ideas?

  • The log is exactly as it should be up to the select timeout error. If nothing suspicions comes up in the dmesg output, as suggested here (https://github.com/analogdevicesinc/aditof_sdk/issues/337), the only remaining reason for this behavior would be a hardware issue and you should contact your sales representative to replace the system.

  • Hi,

    Thanks for your reply.


    I think it is not a hardware problem because when  I started the adi tof demo exemple
    with dmseg --follow command in background, and I have the following output:

    [ 6.467920] addi9036 0-0064: addi9036 detected at address 0x64
    ...
    47.902774] addi9036 0-0064: could not write to register 0
    [ 47.902783] addi9036 0-0064: could not write to register 0
    [ 47.902788] addi9036 0-0064: could not write to register 0
    [ 47.902793] addi9036 0-0064: could not write to register 0
    [ 47.902797] addi9036 0-0064: could not write to register 0
    [ 47.902802] addi9036 0-0064: could not write to register 0

    Does it mean that something is blocking writing to the register 0?

Reply
  • Hi,

    Thanks for your reply.


    I think it is not a hardware problem because when  I started the adi tof demo exemple
    with dmseg --follow command in background, and I have the following output:

    [ 6.467920] addi9036 0-0064: addi9036 detected at address 0x64
    ...
    47.902774] addi9036 0-0064: could not write to register 0
    [ 47.902783] addi9036 0-0064: could not write to register 0
    [ 47.902788] addi9036 0-0064: could not write to register 0
    [ 47.902793] addi9036 0-0064: could not write to register 0
    [ 47.902797] addi9036 0-0064: could not write to register 0
    [ 47.902802] addi9036 0-0064: could not write to register 0

    Does it mean that something is blocking writing to the register 0?

Children