How to make Argus in Jetson 35.2.1 recover after a corrupted frame?

[jhnlmn]

Hi,
This is a follow up to

How to make Argus recover after a corrupted frame?

Hi, In modern robotics camera cables often lay close to high power motor and other cables and occasional burst of EMI noise is unavoidable. That’s why MIPI frames are protected with CRC - so that ISP can ignore occasional bad frame and continue. But Argus capture breaks down even after a single corrupted frame with errors like: “General error queue is out of sync with frame queue” Jan 25 15:45:24 orin2 nvargus-daemon[2606]: (Argus) Error Timeout: (propagating from src/api/CaptureSessionImp…

We really need to make Jetson MIPI camera work in a mission critical system and we cannot have Argus abort after every corrupted frame.
Corrupted frames are unavoidable in most modern robotic systems because of EMI noise from motors are instruments.

I see that you are giving some people custom versions of camera-rtcpu-t234-rce.img with special features.
I wonder whether it is possible to make a version of camera-rtcpu-t234-rce.img, which will:

1. Check CRC and reject corrupted frames
2. Simply drop corrupted frames, do not report errors to argus, so that it will not abort the capture session, like it does now.
   Or, may be, there are settings to the existing FW, which can achieve the same?

Note: the simplest way to reproduce the failure is to briefly short D+/D- lines in MIPI bus together or to the ground. (I was told by sensor makers that this is normally a safe thing to do).
Then you will see corrupted images on the screen and them Argus will abort with errors:
Mar 30 15:39:04 orin2 kernel: [RCE] ERROR: camera-ip/vi5/vi5.c:745 [vi5_handle_eof] “General error queue is out of sync with frame queue. ts=54628931184736 sof_ts=54628998768736 gerror_code=2 gerror_data=a2 notify_bits=0”
Mar 30 15:39:09 orin2 nvargus-daemon[8753]: === argus_multi_camera[8963]: CameraProvider initialized (0xffff488d9bb0)SCF: Error InvalidState: Timeout waiting on frame start sensor guid 1, capture sequence ID = 657 (in src/service
s/capture/FusaCaptureViCsiHw.cpp, function waitCsiFrameStart(), line 514)

Thank you

[JerryChang]

hello jhnlmn,

it looks error handling mechanism did not works, we do reproduce the issue locally.
test environment… l4t-r35.3.1 + AGX Orin + IMX274.

let us check this issue internally.

[pepijn.vanheiningen]

Would like to second this issue, we have the same problems. If there is anything we can do to help, let us know!

(see JP5.1 nvarguscamera doesn't recover from single NVCSI failure)

[jhnlmn]

@JerryChang
Any progress? Any hope of fixing it? We have an important demo next month and need to make camera stable.
If Nvidia cannot fix this SW, would it be possible to get sources for the camera FW ( may be under NDA ) so that we fix it ourselves?
Thank you