Zeros in received frame on Xavier NX / L4T 32.5

Also, could you please run

media-ctl --print-dot > graph.dot
dot -Tpng graph.dot > graph.png

Trying with the pre-built image now. Seems the corruption problem is fixed, thanks

No, I am getting the same thing with the pre-build image as with my image. No errors from aditof-demo, just zeros in the frame

The dmesg log : dmesg.log

The output of media-ctl seems fine as I get the same on my device that works fine.

Try to build and run v2.0.0.
When running the example do all 3 LEDs light up?

Also, please do the following checks:
 The dip switches on the camera are set correctly (S1 and S5) to RPI Conf as seen on the silk screen.
 The camera is turned on before turning on the board
 The flat flex is connected to CAM1
 The flat flex is connected the same way on both connectors.

Double checked this list, tried with v2.0.0 and current master. All 3 LEDs light up, I2C communication seems fine but no video.

Also tried removing WiFi module / HDMI and used ssh -Y over wired LAN, no luck either. Checked again with DragonBoard, sensor itself seems fine, although different connector / devicetree...

Is there any way to use the reset signal on Jetsons? I saw that dragonBoard's devicetree defines a GPIO for reset but there is none for XavierNX

It might be irrelevant but please try to run the demo like this:

sudo ./aditof-demo

Hi, yes, I always use root (getting EEPROM access errors otherwise) and the binary from the build directory

Could you print some values fro pdata[i] right after this line https://github.com/analogdevicesinc/aditof_sdk/blob/master/sdk/src/connections/target/addi9036_sensor.cpp#L554 ?
In order make sure that the zeros are coming from the sensor and it is not a deinterleaving issue

It gets zeros, but at <1 FPS, (timeout?)

i changed it to  this:

    for (unsigned int i = 0; i < m_implData->numVideoDevs; i++) {
        dev = &m_implData->videoDevs[i];
        status = getInternalBufferPrivate(&pdata[i], buf_data_len, buf[i], dev);

printf("%u, %u, %u:\n",i, (uint8_t)status, buf_data_len);
for (size_t j = 0; j < 100; j++)
	printf("%u,", pdata[i][j]);
printf("\n");

        if (status != Status::OK) {
            return status;
        }
    }
    

and i get:

0, 0, 921600:
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
1, 0, 921600:
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,

It must be a HW issue, tried also with RPi 4B, same issue. I2C is fine, fails to get frames. It only works with dragonboard. Do those connectors share the same lines or there is an interface IC ?

S5 is responsible for switching the I2C lines from "Dragonboard mode" and "RPI mode".

yes but I2C communication seems fine, both Xavier and RPi can turn on the LEDs and communicate.

yes but I2C communication seems fine, both Xavier and RPi can turn on the LEDs and communicate.

It seems like the MIPI line is broken. Have you tried to use another flat-flex cable?

Yes, tried with a couple of them also some brand new. The markings on the flex cable's contacts  seem to indicate proper connection, but still no luck

Hi,
As I thought, the MIPI line is broken.
I ran the example with S1 in the wrong configuration and I got the same results as you.
The first step would be to check the voltage on the SEL line. If the value is fine (3.5V) you could check if U11 and U7 are powered.

Nice, i will have a look a bit later today. Thanks

Have you got any results?

Hi, yes everything look normal, 3.5V at the switch and at the power supply capacitors. 

I guess we will have to live with the DragonBoard, for the moment at least.

Thanks for the support