Argus capture issue when mipi datarate is higher than 1.5gbps

Autonomous Machines Jetson & Embedded Systems Jetson AGX Orin
,
1

Hi all,

We are facing a problem while trying to capture with nvarguscamerasrc when the datarate is set above 1.5gbps, however, we can successfully capture using V4L2.

This is the setup information:

  • JP: 5.1.1
  • Board: AGX Orin Devkit
  • SerDes: GMSL2
  • Mipi: 2 data lanes
  • DataRate: 1.4gbps (V4L2 and Argus working) and 2.0gbps(V4L2 working, Argus fails).

We are aware about the new deskew setup requirement when using high datarate, in fact, we already enabled the deskew and that’s why V4L2 works, if I disable the deskew in the 2gbps case, I’m unable to capture which makes sense according to the new requirements for JP5. The serdes_pix_clk is being adjusted to the testing datarate.

So, I assuming there is a timing problem specific with Argus and I’m looking for a solution, what else is configurable on the device-tree or somewhere else to change the timings for the Argus pipeline?

This is the testing pipeline for nvarguscamerasrc:

gst-launch-1.0 nvarguscamerasrc ! ‘video/x-raw(memory:NVMM), width=1456, height=1088, framerate=(fraction)60/1, format=NV12’ ! queue ! fakesink silent=false -v

This is the error shown on the console:

nvbuf_utils: dmabuf_fd -1 mapped entry NOT found
Error generated. gstnvarguscamerasrc.cpp, threadExecute:694 NvBufSurfaceFromFd Failed.
Error generated. gstnvarguscamerasrc.cpp, threadFunction:247 (propagating)

On the trace I see the next sequence:

                            _-----=> irqs-off
                           / _----=> need-resched
                          | / _---=> hardirq/softirq
                          || / _--=> preempt-depth
                          ||| /     delay
       TASK-PID     CPU#  ||||   TIMESTAMP  FUNCTION
          | |         |   ||||      |         |

 kworker/3:7-625     [003] ....   184.360224: rtcpu_string: tstamp:6923664849 id:0x04010000 str:"VM0 deactivating."
 kworker/3:7-625     [003] ....   192.152225: rtcpu_string: tstamp:7166019202 id:0x04010000 str:"VM0 activating."
 kworker/3:7-625     [003] ....   193.104234: rtcpu_nvcsi_intr: tstamp:7195725850 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x0e000000
 kworker/3:7-625     [003] ....   193.104238: rtcpu_nvcsi_intr: tstamp:7195725850 class:CORRECTABLE_ERR type:PHY_INTR phy:0 cil:0 st:0 vc:0 status:0x00000e00
 kworker/3:7-625     [003] ....   193.104240: rtcpu_vinotify_event: tstamp:7195749590 cch:1 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:230262503072 data:0x399d580010000000
 kworker/3:7-625     [003] ....   193.104240: rtcpu_vinotify_event: tstamp:7195749734 cch:1 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:230262545792 data:0x0000000031000001
 kworker/3:7-625     [003] ....   193.104241: rtcpu_nvcsi_intr: tstamp:7196246680 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x0e000000
 kworker/3:7-625     [003] ....   193.104242: rtcpu_nvcsi_intr: tstamp:7196246680 class:CORRECTABLE_ERR type:PHY_INTR phy:0 cil:0 st:0 vc:0 status:0x00000e00
 kworker/3:7-625     [003] ....   193.104242: rtcpu_vinotify_event: tstamp:7196292725 cch:1 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:230278791104 data:0x399d550010000000
 kworker/3:7-625     [003] ....   193.104243: rtcpu_vinotify_event: tstamp:7196292862 cch:1 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:230278834464 data:0x0000000031000002
 kworker/3:7-625     [003] ....   193.104244: rtcpu_nvcsi_intr: tstamp:7196767508 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x0e000000
 kworker/3:7-625     [003] ....   193.104244: rtcpu_nvcsi_intr: tstamp:7196767508 class:CORRECTABLE_ERR type:PHY_INTR phy:0 cil:0 st:0 vc:0 status:0x00000e00
 kworker/3:7-625     [003] ....   193.160236: rtcpu_nvcsi_intr: tstamp:7197288336 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x0e000000
 kworker/3:7-625     [003] ....   193.160239: rtcpu_nvcsi_intr: tstamp:7197288336 class:CORRECTABLE_ERR type:PHY_INTR phy:0 cil:0 st:0 vc:0 status:0x00000e00

Any suggestion is highly appreciated.

3

hello greivin.fallas,

truth is…
we got an issue that V4L v.s. Argus were having different timing for waiting deskew signal. the comparison result shows it’s Argus waits for signal too early.

you may have to workaround this by configure sensor state as standby (not streaming), then switch the sensor state to stream after a short while.
practically,
you may have schedule_delayed_work() to delay the low-level sensor driver to delay start stream for ~100ms (or more, depends-on your real use-case) for testing.

FYI,
we have fixes check-in to revise the sensor init sequence to address the timeout failure with deskew calibration.
please note that deskew calibration fixes will be deliver with the next JetPack public release. i.e. JetPack-5.1.2.

1 Like
4

Hi @JerryChang ,

Thanks for your answer, is there a estimate for the JetPack release date?

5

hello greivin.fallas,

sorry, I don’t have solid release schedule, it shall be available on the 2nd half of this year.

1 Like
7

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