CSI issue between AGX Xavier and AWR2243 radar chipset

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

Hello,

we developped a PCB to connect a Jetson AGX Xavier devkit to a Texas Instruments MMWCAS-RF-EVM Evaluation board which is made of four AWR2243 radar chipsets.

We control the radar chips through SPI and GPIO and that part is working well.

These chips have a CSI2 D-PHY interface to transfert radar data to a host, and we struggle to make this work. Each chipset has four RX channels, hence we plan to use the 4x4 CSI configuration to get all the 16 RX radar channels, but radar chips can be configured to use all or only one lane.

We saw a lot of topics related to AWR2243-Jetson CSI issues [1][2][3][4], but we didn’t find any solution to our problem.

The kernel is the latest one for this board: 5.10.216 (Jestson Linux 35.6.0).

To avoid any problem due to signal integrity we reduce the camera CSI clock frequency to 75MHz. The image size is 256x32 (16 bits per pixel).

We validated the radar CSI configuration with an oscilloscope. We can see the Start of Frame, Line Start, datas, Line End, …, Line Start, datas, Line End, End Of Frame.

Unfortunately we are unable to capture an image with V4L2.

1) 4 CSI lanes per radar chip

On the debug console we see a timeout whatever the radar chip. Please refer to
log_video0_4lanes.txt (1.1 KB)

On the traces we see interrupts and flags. However in the source code we did not find the meaning of those flags. Can you please analyse trace_videoX_4lanes.txt files trace_video0_4lanes.txt (502.8 KB)
trace_video1_4lanes.txt (526.2 KB)
trace_video2_4lanes.txt (546.6 KB)
trace_video3_4lanes.txt (526.2 KB)
and tell us what is going wrong on the CSI when 4 lanes are used?

2) 1 CSI lane per radar chip

On the debug console we see errors and then a timeout. Please refer to log_video0_1lane.txt
log_video0_1lane.txt (2.4 KB)
It looks like the problem is coming from the End Of Frame:

[ 208.569339] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 131072
cap dqbuf: 0 seq: 0 bytesused: 16384 ts: 0.000000 (error, ts-monotonic, ts-src-eof)

err_data 131072 is 0x20000. It means bit #17 is at 1.

In nvidia/include/soc/tegra/camrtc-capture.h:

/* Frame end was forced by channel reset /
define CAPTURE_CHANNEL_ERROR_FORCE_FE MK_BIT32(17)

Can you please confirm this error? In that case what can be the root cause of such an error? At the oscilloscope everything seems to be fine.

On the traces the flags are not the same as the ones with 4 CSI lanes. Can you please analyse trace_video0_1lane.txt files
trace_video0_1lane.txt (1.4 MB)
and tell us what is going wrong on the CSI when 1 lane is used?

3) Device tree

Can you please check our device tree file for both configurations (tegra194-camera-e3326-a00-Xlane.dtsi)?
tegra194-camera-e3326-a00-1lane.dtsi.txt (12.7 KB)
tegra194-camera-e3326-a00-4lanes.dtsi.txt (12.7 KB)

4) Other questions

Is there any errata/limitations on the CSI controller?

We saw that RidgeRun has developped a driver for this AWR2243 chip [5], so there should not be any hardware limitation, unless the CSI controller has changed between Xavier generation and Orin generation ?

[1] https://forums.developer.nvidia.com/t/receives-csi-data-without-i2c-and-device-tree-questions-for-none-camera-sensor/192698

[2] https://forums.developer.nvidia.com/t/jetson-agx-xavier-and-ti-mmwave-radar-raw-data-capture-over-csi/83198

[3] https://forums.developer.nvidia.com/t/video-driver-port-from-tx2-nx-jp4-6-4-to-orin-nx-jp5-1-3/293265

[4] https://forums.developer.nvidia.com/t/jetson-mipi-csi-2-timeout/266521/10

[5] https://developer.ridgerun.com/wiki/index.php/Texas_Instruments_AWR2243_Linux_driver

3

Looks like incorrect cil_settletime cause the problem.
Set it to 0 to verify.

4

Hello,

Thanks for you help.

I tried with cil_settletime at 0 but still the same error on V4L2:
log_video0_1lane_cil_settletime0…txt (3.9 KB)

However the traces are not the same:
trace_video0_1lane_cil_settletime0.txt (45.6 KB)

It looks to be better but still not working.

5

The error tells the output lines less than driver report.
What’s the “Bytes per Line” shows by v4l2-ctl --all?

 kworker/2:3-139     [002] ....   150.751129: rtcpu_vinotify_event: tstamp:5435213569 cch:0 vi:0 tag:CHANSEL_SHORT_FRAME channel:0x01 frame:0 vi_tstamp:173926261568 data:0x0000200001000000
6

The “Bytes per Line” returned by v4l2-ctl --all is 512.
v4l2_ctl.txt (3.8 KB)

How can we know the number of bytes received?

7

The error is the lines less than 32.

8

How can we know the number of lines received by the SW?

We checked with an oscilloscope and there are 32 lines sent by the transmitter. What can cause the CSI receiver to discard some lines?

9

Current don’t have a way to know received lines.
You can modify the sensor to report less lines to verify.
Need to confirm the modification by v4l2-ctl --all

10

v4l2-ctl --all still show 32 lines when the sensor driver report less than 32 lines. It seems to be a SW limitation in the kernel. So I modified the camera configuration. Now the camera is sending 128 lines. I verified with an oscilloscope.

Then I modified the driver to report less than 128 lines and verified with v4l2-ctl --all. I tried with different values down to 32 lines. Unfortunately the error messages are still the same.

I also tried with the driver reporting 128 lines and more. The error messages are still the same.

11

Boost the clocks and apply the patch from below link to check again.

12

I applied the patch.

Then I increased the clocks frequency. I tried all the combinations with:

  • pix_clk_hz in the device tree = 75000000, 25000000, 89100000, 150000000
  • camera output clock configuration (Mbps) = 150, 225, 300, 400

Depending on the combination the result is either a timeout or CHANSEL_SHORT_FRAME error.

I did the same tests with the driver reporting a crop image (128x64). For each combinations above I got the same result as the driver reporting a full image (256x128).

13

Get the trace log after applying the patch.

14

Log and trace after applying the patch:
log_video0_1lane_cil_settletime0_patch.txt (4.2 KB)
trace_video0_1lane_cil_settletime0_patch.txt (48.8 KB)

I don’t think the patch can help for our problem because they are fixing:

  • memory leak
  • race condition
  • kernel panic
15

Add below to the vi5_setup_surface() at vi5_fops.c to check if able to enable the log for getting number of lines.

desc->ch_cfg.line_timer_enable = 1;
desc->ch_cfg.line_timer_periodic = 1;
16

Here’s the change for it. Need to add line_timer also.
You should able see the log like below from the trace log.
The data data:0x0000000001ff0010 mean receive 512(1ff) lines.

    kworker/0:15-204     [000] ....   100.232670: rtcpu_vinotify_event: tstamp:4258617261 cch:0 vi:0 tag:CHANSEL_NLINES channel:0x23 frame:1 vi_tstamp:136266784672 data:0x0000000001ff0010

diff --git a/drivers/media/platform/tegra/camera/vi/vi5_fops.c b/drivers/media/platform/tegra/camera/vi/vi5_fops.c
index 2b601c971..705f9e231 100644
--- a/drivers/media/platform/tegra/camera/vi/vi5_fops.c
+++ b/drivers/media/platform/tegra/camera/vi/vi5_fops.c
@@ -415,6 +415,10 @@ static void vi5_setup_surface(struct tegra_channel *chan,
        desc->ch_cfg.pixfmt_enable = 1;
        desc->ch_cfg.pixfmt.format = format;

+       desc->ch_cfg.line_timer_enable = 1;
+       desc->ch_cfg.line_timer_periodic = 1;
+       desc->ch_cfg.line_timer = 2;
+
17

Good news if we can get number of lines.
However I applied the patch but I don’t have the tag CHANSEL_NLINES in the log. I verified that vi5_setup_surface is called.

See:
trace_video0_1lane_cil_settletime0_patch_line.txt (57.1 KB)
vi5_fops.c.txt (27.5 KB)

I added .txt extension to the source code because we can’t upload .c file.

I think the trace is enabled because we can see others rtcpu_vinotify_event traces. Or maybe there is a specific trace to be enabled?

18

Looks like the incorrect pixel format.
The error report data type RAW8 but driver report YUV.

     kworker/1:0-2259    [001] ....   395.880251: rtcpu_vinotify_event: tstamp:13086957395 cch:0 vi:0 tag:CHANSEL_NOMATCH channel:0x01 frame:0 vi_tstamp:418770620448 data:0x0000000000000549
1 Like
20

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.