JetPack 4.4: XGS12M driver 4176x2168@30fps resolution issue

Hello. I am currently working on the bring up of a XGS12M device driver under L4T 32.4.3 (JetPack 4.4). The sensor configuration is set for 4176x2168, however it is always sent an additional embedded data line of height 1 (this can not be switched off).

  1. The only way we have been able to capture is by defining the resolution to 4176x2169 in the “camera_common_frmfmt” struct and “device tree mode node”. It does not matter if the “embedded_metadata_height” field is set to 1 or 0, it works both ways.

  2. If instead we set the resolution to 4176x2168 and use embedded_metadata_height=1. We get the following VI trace log:

kworker/4:0-36    [004] ....   931.835588: rtcpu_vinotify_event: tstamp:29260383355 tag:CHANSEL_PXL_SOF channel:0x00 frame:24964 vi_tstamp:29260382814 data:0x00000001
     kworker/4:0-36    [004] ....   931.835596: rtcpu_vinotify_event: tstamp:29260383574 tag:ATOMP_FS channel:0x00 frame:24964 vi_tstamp:29260382819 data:0x00000000
     kworker/4:0-36    [004] ....   931.835598: rtcpu_vinotify_event: tstamp:29260387183 tag:CHANSEL_LOAD_FRAMED channel:0x01 frame:24964 vi_tstamp:29260386790 data:0x08000000
     kworker/4:0-36    [004] ....   931.835601: rtcpu_vinotify_event: tstamp:29261415758 tag:CHANSEL_PXL_EOF channel:0x00 frame:24964 vi_tstamp:29261414861 data:0x08770002
     kworker/4:0-36    [004] ....   931.835603: rtcpu_vinotify_event: tstamp:29261415923 tag:CHANSEL_FAULT channel:0x00 frame:24964 vi_tstamp:29261414930 data:0x08780040
     kworker/4:0-36    [004] ....   931.835605: rtcpu_vinotify_event: tstamp:29261416150 tag:ATOMP_FE channel:0x00 frame:24964 vi_tstamp:29261415362 data:0x00000000

Any insight you could provide about this issue would be really useful.

Current only support embedded data in top of frame.

Hi, ShaneCCC. Thanks for the information provided. We adjusted the sensor configuration and we are currently capturing 4176x2170 with embedded_metadata_height = “1”.

Now we have been focused on trying to capture with nvarguscamerasrc but we are encountering some issues. With v4l2-ctl command we are able to capture without issues:

*v4l2-ctl command

v4l2-ctl -d /dev/video0 --set-fmt-video=width=4176,height=2170,pixelformat=BG12 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=-1

However trying to capture with a gst-launch command causes to get some errors. Please check VI trace and nvargus-daemon debug log below:

*gst-launch command

v4l2-ctl -d /dev/video0 --set-fmt-video=width=4176,height=2170,pixelformat=BG12 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=-1

*VI trace

     kworker/3:3-2359  [003] ....   232.501543: rtcpu_vinotify_event: tstamp:7406246303 tag:ISPBUF_FS channel:0x00 frame:548 vi_tstamp:7406245685 data:0x00000000
     kworker/3:3-2359  [003] ....   232.501552: rtcpu_vinotify_event: tstamp:7406246455 tag:CHANSEL_PXL_SOF channel:0x00 frame:548 vi_tstamp:7406246024 data:0x00000001
     kworker/3:3-2359  [003] ....   232.501555: rtcpu_vinotify_event: tstamp:7407279838 tag:CHANSEL_PXL_EOF channel:0x00 frame:548 vi_tstamp:7407279016 data:0x08790002
     kworker/3:3-2359  [003] ....   232.501557: rtcpu_vinotify_event: tstamp:7407279991 tag:CSIMUX_FRAME channel:0x00 frame:548 vi_tstamp:7407279040 data:0x00400060
     kworker/3:3-2359  [003] ....   232.501559: rtcpu_vinotify_event: tstamp:7407280217 tag:ISPBUF_FE channel:0x00 frame:548 vi_tstamp:7407279041 data:0x00000000

*nvargus-daemon

NvPclHwGetModuleList: WARNING: Could not map module to ISP config string
NvPclHwGetModuleList: No module data found
OFParserGetVirtualDevice: NVIDIA Camera virtual enumerator not found in proc device-tree
---- imager: No override file found. ----
LSC: LSC surface is not based on full res!
=== gst-launch-1.0[7897]: CameraProvider initialized (0x7fac742150)LSC: LSC surface is not based on full res!
NvViErrorDecode Stream 0.0 failed: ts 237032929280 frame 548 error 2 data 0x00400060
NvViErrorDecode CaptureError: CsimuxFrameError (2)
NvViErrorDecode See https://wiki.nvidia.com/wmpwiki/index.php/Camera_Debugging/CaptureError_debugging for more information and links to documents.
CsimuxFrameError_Regular : 0x00400060
    Stream ID                [ 2: 0]: 0
        
    VPR state from fuse block    [ 3]: 0
        
    Frame end (FE)              [ 5]: 1
        A frame end has been found on a regular mode stream.
    CSI_FAULT                   [ 6]: 1
        An FE packet was found and marked with a CSI Error
    CSI_CODE                 [25:20]: 0x4
        Check the CSI specification for the meaning. See https://wiki.nvidia.com/wmpwiki/index.php/Camera_Debugging/CaptureError_debugging#CSI_CODE
SCF: Error InvalidState:  (propagating from src/services/capture/NvViCsiHw.cpp, function startCapture(), line 508)
SCF: Error InvalidState:  (propagating from src/services/capture/DeviceRecordNv.cpp, function doCSItoISPCapture(), line 110)
SCF: Error InvalidState:  (propagating from src/services/capture/CaptureRecord.cpp, function doCSItoISPCapture(), line 547)
SCF: Error InvalidState:  (propagating from src/services/capture/CaptureRecord.cpp, function issueCapture(), line 460)
SCF: Error InvalidState:  (propagating from src/services/capture/CaptureServiceDevice.cpp, function issueCaptures(), line 1293)
SCF: Error InvalidState:  (propagating from src/services/capture/CaptureServiceDevice.cpp, function issueCaptures(), line 1124)
SCF: Error OverFlow:  (propagating from src/services/capture/CaptureServiceDevice.cpp, function returnRequestPoolCaptures(), line 1243)
captureErrorCallback Stream 0.0 capture 3 failed: ts 237032929280 frame 548 error 2 data 0x00400060

SCF: Error BadValue: timestamp cannot be 0 (in src/services/capture/NvViCsiHw.cpp, function waitCsiFrameStart(), line 630)
SCF: Error BadValue:  (propagating from src/common/Utils.cpp, function workerThread(), line 116)
SCF: Error BadValue: Worker thread ViCsiHw frameStart failed (in src/common/Utils.cpp, function workerThread(), line 133)
SCF: Error Timeout:  (propagating from src/api/Buffer.cpp, function waitForUnlock(), line 637)
SCF: Error Timeout:  (propagating from src/components/CaptureContainerImpl.cpp, function returnBuffer(), line 358)
SCF: Error InvalidState:  (propagating from src/common/Utils.cpp, function workerThread(), line 116)
SCF: Error InvalidState: Worker thread CaptureScheduler frameStart failed (in src/common/Utils.cpp, function workerThread(), line 133)
SCF: Error Timeout:  (propagating from src/api/Buffer.cpp, function waitForUnlock(), line 637)
SCF: Error Timeout:  (propagating from src/components/CaptureContainerImpl.cpp, function returnBuffer(), line 358)
SCF: Error Timeout:  (propagating from src/api/Buffer.cpp, function waitForUnlock(), line 637)
SCF: Error Timeout:  (propagating from src/components/CaptureContainerImpl.cpp, function returnBuffer(), line 358)
SCF: Error Timeout: ISP port 0 timed out! (in src/services/capture/NvIspHw.cpp, function waitIspFrameEnd(), line 478)
SCF: Error Timeout: ISP Stats timed out! (in src/services/capture/NvIspHw.cpp, function waitIspStatsFinished(), line 561)
SCF: Error Timeout: ISP port 1 timed out! (in src/services/capture/NvIspHw.cpp, function waitIspFrameEnd(), line 501)
SCF: Error Timeout: ISP Stats timed out! (in src/services/capture/NvIspHw.cpp, function waitIspStatsFinished(), line 561)
SCF: Error Timeout: Sending critical error event (in src/api/Session.cpp, function sendErrorEvent(), line 990)
SCF: Error BadParameter: CC has already been disposed (in src/components/CaptureContainerManager.cpp, function dispose(), line 161)
SCF: Error Timeout: ISP port 2 timed out! (in src/services/capture/NvIspHw.cpp, function waitIspFrameEnd(), line 512)
SCF: Error Timeout:  (propagating from src/services/capture/NvIspHw.cpp, function waitIspFrameEnd(), line 519)
SCF: Error Timeout:  (propagating from src/common/Utils.cpp, function workerThread(), line 116)
SCF: Error Timeout: Worker thread IspHw frameComplete failed (in src/common/Utils.cpp, function workerThread(), line 133)
=== gst-launch-1.0[7897]: Connection closed (7FB14311D0)=== gst-launch-1.0[7897]: WARNING: CameraProvider was not destroyed before client connection terminated.=== gst-launch-1.0[7897]:          The client may have abnormally terminated. Destroying CameraProvider...=== gst-launch-1.0[7897]: CameraProvider destroyed (0x7fac742150)=== gst-launch-1.0[7897]: WARNING: Cleaning up 1 outstanding requests...=== gst-launch-1.0[7897]: WARNING: Cleaning up 1 outstanding streams...SCF: Error InvalidState: 2 buffers still pending during EGLStreamProducer destruction (propagating from src/services/gl/EGLStreamProducer.cpp, function freeBuffers(), line 306)
SCF: Error InvalidState:  (propagating from src/services/gl/EGLStreamProducer.cpp, function ~EGLStreamProducer(), line 50)
=== gst-launch-1.0[7897]: WARNING: Cleaning up 1 outstanding stream settings...=== gst-launch-1.0[7897]: WARNING: Cleaning up 1 outstanding sessions...SCF: Error Timeout:  (propagating from src/services/capture/CaptureServiceEvent.cpp, function wait(), line 59)
Error: Camera HwEvents wait, this may indicate a hardware timeout occured,abort current/incoming cc
waitForIdleLocked remaining request 103 
waitForIdleLocked remaining request 102 
SCF: Error Timeout: waitForIdle() timed out (in src/api/Session.cpp, function waitForIdleLocked(), line 920)
(Argus) Error Timeout:  (propagating from src/api/CaptureSessionImpl.cpp, function destroy(), line 166)

The “CSIMUX_FRAME” values suggests that we are gettings CRC error on payloads. We already applied the following patch here (which is actually needed to capture at least with a v4l2-ctl command) but still getting errors with nvarguscamerasrc after applying that patch.

Any insight you could provide is very valuable.

Regards,

There was a mistake in the gst-launch that was supposed to be posted above, this is the correct one:

gst-launch-1.0 nvarguscamerasrc sensor-id=0 aelock=1 ! \
'video/x-raw(memory:NVMM), width=(int)4176, height=(int)2170, format=(string)NV12,framerate=(fraction)30/1' ! \
fakesink silent=false -v

For the CRC error we don’t have workaround like csi4_fops.c to avoid it.
I would suggest to modify the sensor to output CRC package if possible.

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