GMSL camera bringup on Xavier NX

Robotics & Edge Computing Jetson & Embedded Systems Jetson Xavier NX
1

Hi Team,

I am facing issue in GMSL camera bringup on Xavier NX.
camera setup: Max9288 deserializer <–>Max96705 serializer with isx019 sensor

After device boot up,

I am able to read i2c regsiters of serializer and deserializer but camera registers are showing as “00”. Any idea how to debug this?

serializer(Max96705):
$ i2cdump -f -y 1 0x40
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 80 90 ff 00 83 00 a0 b0 01 00 00 de 80 36 02 3e ??..?.???..??6?>
10: 02 42 40 02 60 e3 08 90 ff ff ff ff 00 00 41 01 ?B@?`???..A?
20: 07 06 05 04 03 02 01 00 08 09 0a 0b 0c 0d 0e 0f ???.???
30: 17 16 15 14 13 12 16 17 18 19 1a 1b 1c 1d 1e 10 ???
40: 0f 10 5b 15 00 9c 80 00 b0 00 00 00 00 40 00 00 ??[?.??.?..@…
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
60: 00 00 00 00 00 00 61 c4 19 0f 00 00 00 00 00 00 …a???..
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
90: 00 00 00 00 00 00 06 5f 4a 0d 10 00 00 00 00 00 …?_J??..
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
c0: 00 00 00 00 00 00 00 00 0a ff 00 00 00 00 00 00 …?..
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …

Deserializer(Max9288):
$ i2cdump -f -y 1 0x48
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 80 90 1f 00 83 29 1f 54 20 40 0c 20 00 00 00 f7 ???.?)?T @? …?
10: 40 42 00 20 00 70 5a 1d 00 00 00 00 36 00 2a 03 @B. .pZ?..6.*?
20: 00 00 00 00 00 00 00 00 00 80 80 03 00 06 19 03 …???.???
30: 45 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 E…?..
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
60: 20 00 00 00 0c 57 e4 00 c8 00 00 00 00 00 00 00 …?W?.?..
70: 00 00 00 02 5b 02 0a ff ff 70 00 00 00 00 00 00 …?[??..p…
80: ff fa bd b6 00 00 00 00 00 00 00 00 00 00 00 00 .???..
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …

sensor(isx019):
$ i2cdump -f -y 1 0x1a
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …

@SteveNV
@ShaneCCC
@SimonZhu

Thanks,
Arun

2

The sensor address length may not 8 bit like Max9288/Max92705, it could be 16bit address length.
You may need to check the REG read/write by the driver would be better.

3

@ShaneCCC

I have checked in driver, it is 8-bit address only.

4

If there’s no any kernel i2c error message I think you may need to consult with vendor.

5

Does the value are 8 bits too?

6

sensor has 16-bit registers.
always i2cdump of sensor shows zero.

i2cdump -y -f 1 0x1a
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …

How to debug this?

7

I don’t think i2cdump support 16 bit address.
It’s better to implement a kernel driver to access it.

8

@ShaneCCC

Thanks for the reply, I am able to sensor registers from the kernel driver.

I am getting these error while trying to do camera capture,

[ 1260.910342] [RCE] vi5_hwinit: firmware CL2018101701 protocol version 2.2
[ 1263.438244] tegra194-vi5 15c10000.vi: no reply from camera processor
[ 1263.438401] tegra194-vi5 15c10000.vi: uncorr_err: request timed out after 2500 ms
[ 1263.438573] tegra194-vi5 15c10000.vi: err_rec: attempting to reset the capture channel
[ 1263.440829] tegra194-vi5 15c10000.vi: err_rec: successfully reset the capture channel
[ 1265.998226] tegra194-vi5 15c10000.vi: no reply from camera processor
[ 1265.998376] tegra194-vi5 15c10000.vi: uncorr_err: request timed out after 2500 ms
[ 1265.998546] tegra194-vi5 15c10000.vi: err_rec: attempting to reset the capture channel
[ 1265.998697] tegra194-vi5 15c10000.vi: unexpected response from camera processor
[ 1265.998851] video4linux video0: vi capture release failed
[ 1265.998948] tegra194-vi5 15c10000.vi: fatal: error recovery failed

Thanks,
Arun

9

Check the trace log.

echo 1 > /sys/kernel/debug/tracing/tracing_on
echo 30720 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/tegra_rtcpu/enable
echo 1 > /sys/kernel/debug/tracing/events/freertos/enable
echo 2 > /sys/kernel/debug/camrtc/log-level
echo 1 > /sys/kernel/debug/tracing/events/camera_common/enable
echo > /sys/kernel/debug/tracing/trace
cat /sys/kernel/debug/tracing/trace
10

@ShaneCCC

I have attached trace logs, can you please check once.

Thanks,
Arunlogs.txt (74.3 KB)

11

The log shows NVCSI/VI didn’t receive any validate data from the MIPI bus.

12

@ShaneCCC

Thank you for the reply

How to debug further? any pointers to debug it

Thanks,
Arun

13

You may need to probe the MIPI signal to make sure the output signal are follow the MIPI spec.

14

@ShaneCCC

I am getting these errors,

[ 104.235971] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 32, err_data 163
[ 104.238115] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 32, err_data 163
[ 104.238291] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 32, err_data 163
[ 104.241674] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 32, err_data 163
[ 104.254259] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 32, err_data 163
[ 104.260285] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 32, err_data 163
[ 104.268765] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 32, err_data 163
[ 104.277408] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 32, err_data 163
[ 104.285048] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 32, err_data 163
[ 104.295925] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 32, err_data 163
[ 104.301041] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 32, err_data 163
[ 104.311154] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 32, err_data 163
[ 104.318021] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 32, err_data 163
[ 104.326482] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 32, err_data 163
[ 104.335616] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 32, err_data 163
[ 104.343241] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 32, err_data 163
[ 104.352715] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 32, err_data 163
[ 104.360090] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 32, err_data 163
[ 104.369094] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 32, err_data 163
[ 104.377104] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 32, err_data 163
[ 104.385436] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 32, err_data 163
[ 104.393476] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 32, err_data 163
[ 104.403201] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 32, err_data 163

attached trace logs also. Any idea on this?
cam_logs.txt (494.7 KB)

Thanks,
Arun

15

There are short frame in the trace log. That tell the output lines didn’t as expect. You can reduce the active_h in the device tree to narrow it.

CHANSEL_SHORT_FRAME

And below tell the FIFO overflow you can try to boost the nvcsi/vi clocks to try.

CSIMUX_FRAME channel:0x00 frame:0 vi_tstamp:3665292156 data:0x000000a3

https://elinux.org/Jetson_TX2_Camera_BringUp