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:
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.
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
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:
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).