MIPI-CSI camera getting stuck when affected by RADAR

We are building a camera system for the marine environment that is using MIPI-CSI cameras, namely: 5MP NVIDIA Jetson Nano Camera

When we place our camera in the beam of a marine radar (S-Band) we repeatedly see following error messages in the kernel ring buffer:

[ 669.754759] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 96, err_data 4194402
[ 669.755980] tegra194-vi5 15c10000.vi: err_rec: attempting to reset the capture channel
[ 669.761987] tegra194-vi5 15c10000.vi: err_rec: successfully reset the capture channel

The flags and err_data are not always the same. These error messages usually do not affect our system and I assume this reset of the capture channel is the intended behaviour if there is a “faulty” frame detected.
Anyway, sometimes the error message looks as follows:

[ 669.770404] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 0, err_data 256

So, the value of flags is 0 or 6. Once this happens there is no attempt to reset the capture channel and we cannot get anymore images from the camera.

Is this behaviour, where there is NO attempt to reset the capture channel intended? Or is this an issue of the driver?


Yes, this could be an issue with the device driver. But also particularly in your use case this issue could be at the hardware level (some kind of electromagnetic interference for example). But at least on the device driver side to better understand the errors that are thrown, can you please provide the output of the V4L2 trace log.

  1. To enable it
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 > /sys/kernel/debug/tracing/trace
  1. In a separate terminal run your v4l2-ctl command
  2. Check the output log with:
sudo cat /sys/kernel/debug/tracing/trace

Jafet Chaves,
Embedded SW Engineer at RidgeRun
Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com/
Website: www.ridgerun.com

Thanks for your support!

Attached you can find the output of the V4L2 trace log and the output of dmesg (where the supspicious message has the timestamp 2712)
trace.zip (5.3 MB)


Thanks for the information. In general my guess is that it seems that the VI (Video Input) engine is having issues to interpret the CSI signals correctly (and therefore there are frames that being dropped basically). For testing have you tried increasing the Xavier AGX performance?

nvpmodel -m 0
sudo su
echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked
cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/vi/rate
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/isp/rate
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate

Also there is more information on how to boost the Jetson Xavier clocks in the following links:



We are already running the AGX at maximum performance, so this should not be an issue.


Got it. Then, does the device driver works without issues without the interference of the radar? Do you have a way to measure the MIPI lanes when the image sensor is interfered by the radar? I would fallback to my original hypothesis of the CSI signals being affected (that is what basically the errors are reporting).