Orin Nano CSI2 DPHY Received error when dphy rate is greater than 2.1G

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
,
1

HI， Our environment is Orin Nano Dev 8GB, R35.4.1

  1. Sensor frame header has 10(or other lines) lines of user-defined data（dtype 0x35/0x37）, Sensor is IMX390 2M pixel or IM678 8M pixel, Camera outputs images to ORIN via SerDes
  2. Orin CSI2 DPHY RX set 4lane mode,
  3. Serdes TX DPHY=2.1G and Use IMX390，Orin Nano receives and displays images normally
  4. Serdes TX DPHY=2.1G, and Use IMX678, Orin rtcpu gone bad
  5. Serdes TX DPHY=2.5G, and Use IMX390, Orin rtcpu gone bad
  6. Serdes TX DPHY=2.5G, and Use IMX678, Orin rtcpu gone bad
  7. Filter out user-defined(0x35/0x37) data using serdes，Serdes TX=2.1 or2.5G， Sensor IMX390/IMX678，Orin can receive and display camera images normally
  8. Error log :
[85409.627633] [RCE] BUG: camera-ip/vi5/vi5.c:415 [vi5_check_falcon_failure] "VI FALCON FAILURE: 0x40000000"
[85409.702031] tegra186-cam-rtcpu bc00000.rtcpu: Alert: Camera RTCPU gone bad! restoring it immediately!!
[85410.623639] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 1000 ms
[85410.632913] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[85410.642602] tegra194-vi5 13e40000.host1x:vi1@14c00000: vi_capture_release: control failed, errno 1
[85410.651933] video4linux video1: vi capture release failed
[85410.657542] tegra-camrtc-capture-vi tegra-capture-vi: fatal: error recovery failed
[85412.767195] as_imx390 10-0020: stop cam but nothing todo 0
[85413.791555] tegra194-vi5 13e40000.host1x:vi1@14c00000: capture control message timed out
[85413.799903] tegra194-vi5 13e40000.host1x:vi1@14c00000: vi_capture_control_send_message: failed to send IVC control message
[85413.811596] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=2, csi_port=2
[85413.827477] bwmgr API not supported
[85413.828492] tegra194-vi5 13e40000.host1x:vi1@14c00000: vi_capture_release: setup channel first
[85413.840987] video4linux video1: vi capture release failed

Other attempts：

Under a 2.5G rate, we first send test pattern vc=0 without user-defined data, then send camera (vc=1) with user-defined data, and the camera images can also be received normally.

The above tests are configured with DPHY initialization calibration before the SERDES outputs CSI2 data.

Please help check why there is inconsistency in user-defined data at different DPHY rates. Is it necessary to adjust the configuration of the SerDes DPHY TX, or is there an issue with the Orin DPHY RX RTCPU?

3

Supplementally, with unchanged sensor data, the Orin uses 2-lane 2.5G, and both IMX390 and IMX678 images are received normally.

6

hello gaoming.song,

thanks for status update, it should be an issue with user-defined data instead of data-rate.

FYI,
there’re hardware pixel parser to process embedded metadata and active dimension separately.
it’s device tree property embedded_metadata_height to process metadata height in units of rows,
if that’s user-defined data (dtype 0x35/0x37), you should have extra lines to add-on active_h.

7

The default configuration of the camera device tree sets the pixel dimensions as active_w=1920, active_h=1080, and embedded_metadata_height=1. This configuration can work normally in DPHY low-speed 2.1Gx4lane or DPHY 2.5Gx2Lane mode
Actually, there are a total of 1,094 line of data, which includes ：1,080 lines (pixels) + framestart 1 line embedded_metadata_height+ 10 lines user-defined (date type 0x35/0x37), and 2 lines NULL (dtype 0x10)+frame_end 1 line embedded_metadata_height. The confusion here is determining the appropriate configuration for active_h/embedded_metadata_height.

8

hello gaoming.song,

if I understand correctly, you have 2 embedded metadata lines (top+bottom), 1080 lines for active region, 12 lines (10+2) for user-defined data.
hence, please give it a try with below configuration.. active_w=1920, active_h=1092, and embedded_metadata_height=2.

9

hi, I tried configuring it this way, with active_i=1092 and embedded_stetata-high=2, but orin still crashes;
Moreover, it cannot be explained why the original configuration of low rate can work normally.
In addition, I have two Orin Nano machines with different physical styles for DPHY slots here. One of them, when the speed reaches 2.2G, sends a testpatten containing only piexl data, without user define data and emb data, which also results in rtcpu gone bad. I am not sure if this issue is caused by the physical signal quality here

10

hello gaoming.song,

there’re some camera stability issues with JP-5.1.2.
please see-also Topic 268833, Topic 276217, Topic 305949.
is it a must to stay-on JP-5.1.2/r35.4.1? is it possible for moving forward to the latest JP-5 release version for verifciation?

11

Thank you for your prompt reply. I may update the version and try again when it’s appropriate