[Jeston TX2][JetPack-L4T-3.2.1] We can't get frame from AR0521 sensor.

We integrated AR0521 sensor into TX2 already.
But we can’get frame from AR0521 sensor now.

The tegra camera driver occurred PXL_SOF syncpt timeout during receiving frame.
We can see the first line of frame.
The other lines are black always.

Fail log:
[ 41.969229] start streaming
[ 42.052962] tegra-vi4 15700000.vi: Status: 4 channel:00 frame:0001
[ 42.059280] tegra-vi4 15700000.vi: timestamp sof 52711979808 eof 52711985824 data 0x00000100
[ 42.068568] tegra-vi4 15700000.vi: capture_id 1 stream 0 vchan 0
[ 43.051971] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 44.055967] tegra-vi4 15700000.vi: ATOMP_FE syncpt timeout!
[ 44.062098] stop streaming

Can you help to find why tegra camera driver occur PXL_SOF syncpt timeout?
Thanks
DarkHou

Provide camera trace log first.

root@tegra-ubuntu:/mnt# cat /sys/kernel/debug/tracing/trace

tracer: nop

entries-in-buffer/entries-written: 22/22 #P:4

_-----=> irqs-off

/ _----=> need-resched

| / _—=> hardirq/softirq

|| / _–=> preempt-depth

||| / delay

TASK-PID CPU# |||| TIMESTAMP FUNCTION

| | | |||| | |

 kworker/3:2-270   [003] ...1    73.296322: rtos_queue_peek_from_isr_failed: tstamp:2622862887 queue:0x0b4a3c58
 kworker/3:2-270   [003] ...1    73.296326: rtcpu_start: tstamp:2622864440
 kworker/3:2-270   [003] ...1    73.400372: rtcpu_vinotify_handle_msg: tstamp:2625495801 tag:CHANSEL_PXL_SOF channel:0x00 frame:1 vi_tstamp:2625495030 data:0x00000001
 kworker/3:2-270   [003] ...1    73.400378: rtcpu_vinotify_handle_msg: tstamp:2625496011 tag:ATOMP_FS channel:0x00 frame:1 vi_tstamp:2625495035 data:0x00000000
 kworker/3:2-270   [003] ...1    73.400380: rtcpu_vinotify_handle_msg: tstamp:2625496153 tag:CHANSEL_FAULT channel:0x00 frame:1 vi_tstamp:2625495217 data:0x00000100
 kworker/3:2-270   [003] ...1    73.400382: rtcpu_vinotify_handle_msg: tstamp:2625496993 tag:CHANSEL_LOAD_FRAMED channel:0x01 frame:1 vi_tstamp:2625496298 data:0x08000000
 kworker/3:2-270   [003] ...1    73.400384: rtcpu_vinotify_handle_msg: tstamp:2625497124 tag:CHANSEL_FAULT_FE channel:0x01 frame:1 vi_tstamp:2625496300 data:0x00000001
 kworker/3:2-270   [003] ...1    73.400386: rtcpu_vinotify_handle_msg: tstamp:2625497287 tag:ATOMP_FE channel:0x00 frame:1 vi_tstamp:2625496303 data:0x00000000
 kworker/3:2-270   [003] ...1    73.452382: rtos_queue_peek_from_isr_failed: tstamp:2627863793 queue:0x0b4a3c58
 kworker/3:2-270   [003] ...1    73.608373: rtos_queue_peek_from_isr_failed: tstamp:2632864301 queue:0x0b4a3c58
 kworker/3:2-270   [003] ...1    73.764387: rtos_queue_peek_from_isr_failed: tstamp:2637864803 queue:0x0b4a3c58
 kworker/3:2-270   [003] ...1    73.920368: rtos_queue_peek_from_isr_failed: tstamp:2642865312 queue:0x0b4a3c58
 kworker/3:2-270   [003] ...1    74.076368: rtos_queue_peek_from_isr_failed: tstamp:2647865817 queue:0x0b4a3c58
 kworker/3:2-270   [003] ...1    74.232377: rtos_queue_peek_from_isr_failed: tstamp:2652866325 queue:0x0b4a3c58
 kworker/3:2-270   [003] ...1    74.388358: rtos_queue_peek_from_isr_failed: tstamp:2657866833 queue:0x0b4a3c58
 kworker/3:2-270   [003] ...1    74.596372: rtos_queue_peek_from_isr_failed: tstamp:2662867338 queue:0x0b4a3c58
 kworker/3:2-270   [003] ...1    74.752382: rtos_queue_peek_from_isr_failed: tstamp:2667867847 queue:0x0b4a3c58
 kworker/3:2-270   [003] ...1    74.908369: rtos_queue_peek_from_isr_failed: tstamp:2672868351 queue:0x0b4a3c58
 kworker/3:2-270   [003] ...1    75.064331: rtos_queue_peek_from_isr_failed: tstamp:2677868848 queue:0x0b4a3c58
 kworker/3:2-270   [003] ...1    75.220329: rtos_queue_peek_from_isr_failed: tstamp:2682869354 queue:0x0b4a3c58
 kworker/3:2-270   [003] ...1    75.376345: rtos_queue_peek_from_isr_failed: tstamp:2687869844 queue:0x0b4a3c58
 kworker/3:2-270   [003] ...1    75.376354: rtos_queue_peek_from_isr_failed: tstamp:2688279359 queue:0x0b4a3c58

The trace log show the “PIXEL_LONG_LINE” have a check the output resolution and if this sensor output embedded data line.

kworker/3:2-270 [003] ...1 73.400380: rtcpu_vinotify_handle_msg: tstamp:2625496153 tag:CHANSEL_FAULT channel:0x00 frame:1 vi_tstamp:2625495217 data:0x00000100

CHANSEL_FAULT data bit field
    bit 16:31  LINE_NUMBER
    bit 15	DTYPE_MISMATCH
    bit 14	EMBED_INFRINGE
    bit 13	EMBED_LONG_LINE
    bit 12	EMBED_SPURIOUS
    bit 11	EMBED_RUNAWAY
    bit 10	EMBED_MISSING_LE
    bit 9	PIXEL_SHORT_LINE
    bit 8	PIXEL_LONG_LINE
    bit 7	PIXEL_SPURIOUS
    bit 6	PIXEL_RUNAWAY
    bit 5	PIXEL_MISSING_LE
    bit 4	PIXEL_LINE_TIMER
    bit 3	EMBED_EOF
    bit 2	EMBED_SOF
    bit 1	PIXEL_EOF
    bit 0	PIXEL_SOF

Hi ShaneCCC:
We can get total frame from AR0521 now.
The root cause is we set wrong active_w for AR0521 5M resolution.
The right active_w is 2600 not 2592.

After we solved PIXEL_LONG_LINE issue, we can get frame normally now.
But the color is wrong.

We use color bar mode to test it first.
AR0521 mode is set as color bar mode.

The black color should be (R:0,G:0,B:0)
But the black color become (R:168,G:168,B:168)

DarkHou
!(upload://rAFl1RZvqOkMRjKcgC9ttvgLdyg.png)

Hi ShaneCCC:
Our AR0521 sensor is MIPI 10bit 4-lane.
Resolution is 2600 x 1952.

Pixel format is bayer RGB.
The pixel order is GRBG.

Our device tree setting is below.

dynamic_pixel_bit_depth = "10";
csi_pixel_bit_depth = "10";
mode_type = "bayer";
pixel_phase = "bggr";
pixel_t = "bayer_bggr";

But the color is wrong still.
DarkHou

Enable the nvargus_daemon to check the pixel type is correct.

Hi ShaneCCC:
Can you tell me how to enable nvargus_daemon?
Thanks
DarkHou

Have a reference to below link

https://elinux.org/Jetson_TX2/28.1_Camera_BringUp

Hi ShaneCCC:
I used v4l2-ctl to check pixel format.
The pixel format is right.

The result is below.

root@tegra-ubuntu:/mnt# v4l2-ctl -d /dev/video0 --list-formats-ext
ioctl: VIDIOC_ENUM_FMT
        Type: Video Capture

        [0]: 'BA10' (10-bit Bayer GRGR/BGBG)
                Size: Discrete 2592x1944
                        Interval: Discrete 0.017s (60.000 fps)

DarkHou

Please provide the nvargus_daemon log also.

Hi ShaneCCC:
I tried to catch nvargus_daemon log.

sudo su
kill the process of argus_daemon/nvargus-daemon or nvcamera-daemon 
export enableCamPclLogs=5
export enableCamScfLogs=5
/usr/sbin/argus_daemon(nvargus-daemon)      option for argus
/usr/sbin/nvcamera-daemon   option for gst-launch
 
launch camera from another console

But I can’t see any log for nvargus_daemon.
We use yavta to test our AR0521 sensor.
ex.
yavta -n1 -c1 -fSGRBG10 -s2560x1920 /dev/video0

I don’t know how to launch camera by TX2 default command.

DarkHou

Hi dark.hou,
Can you try setting the following pixel phase in the device tree and test if you are still facing any color artifacts while running the camera application. Also note that pixel_t parameter has been deprecated so I would suggest you to kindly remove it.

pixel_phase = "grbg";

We removed “pixel_phase = “grbg”;” from device tree.
The color is wrong still.

Hi Dark.hou,
You should remove the pixel_t parameter not the pixel_phase. You should replace the pixel phase from bggr to grbg.

Hi waisskharni:
We modified it already.
The color is wrong still.

mode0 { // ar0521_MODE_2560X1920
				mclk_khz = "27000";
				num_lanes = "4";
				tegra_sinterface = "serial_a";
				discontinuous_clk = "no";
				dpcm_enable = "false";
				cil_settletime = "0";

				active_w = "2560";
				active_h = "1920";
				dynamic_pixel_bit_depth = "10";
				csi_pixel_bit_depth = "10";
				mode_type = "bayer";
				pixel_phase = "grbg";

I upload raw data for AR0521 sensor. (ar0521.rar)
We found the raw data is 14bit not 10 bit.
Our AR0521 sensor is set as MIPI 4 lanes and 10 bit. (Resolution 2560 x 1920)

Can you find why our raw data is 14 bit not 10 bit?
DarkHou

ar0521.rar (48.4 KB)

Hi Dark.Hou,
Can you recheck the sensor settings used? Meanwhile can you double-check the camera streaming using “nvgstcapture” application and in another terminal get the nvargus_daemon logs for debugging