- I am not able to receive valid frames, could you please help track down what is wrong with my code/setup?
- I am using Jetpack 5.1.1 with my own driver for the 0x08b40
- v4l2-ctl --stream-mmap -c bypass_mode=0 get trace log
- x8b_test_001.log (260.2 KB)
mclk_khz = "24000";
num_lanes = "4";
tegra_sinterface = "serial_a";
phy_mode = "DPHY";
// lane_polarity = "6";
discontinuous_clk = "no";
dpcm_enable = "false";
cil_settletime = "0";
active_w = "3840";
active_h = "2160";
mode_type = "bayer";
pixel_phase = "rggb";
csi_pixel_bit_depth = "12";
readout_orientation = "0";
// line_length = "4208";
line_length = "3856";
inherent_gain = "1";
mclk_multiplier = "24";
pix_clk_hz = "248832000";
gain_factor = "1000000";
min_gain_val = "1000000";
max_gain_val = "44400000";
step_gain_val = "1";
default_gain = "1000000";
min_hdr_ratio = "1";
max_hdr_ratio = "1";
framerate_factor = "1000000";
min_framerate = "1500000";
max_framerate = "30000000";
step_framerate = "1";
default_framerate= "30000000";
exposure_factor = "1000000";
min_exp_time = "44";
max_exp_time = "478696";
step_exp_time = "1";
default_exp_time = "16667";/* us */
embedded_metadata_height = "6";
// 20251113 修改 tyz
dynamic_pixel_bit_depth = "12";
The pix_clk_hz looks like unreasonable.
Try boost the clocks to try.
sudo su
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
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/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
cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate
During our camera driver development and debugging process, we encountered the following kernel log entry:
rtcpu_nvcsi_intr: tstamp:7293196364 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000004
Technical Questions
1. Source of the ‘vc’ field value
Could you please clarify whether the vc:0 value in this log entry represents:
- The virtual channel ID configured in the Orin’s NVCSI module (i.e., the vc-id specified in the device tree), or
- The virtual channel ID extracted from the incoming CSI data stream (i.e., the VC ID transmitted by the sensor)?
Understanding the source of this value is critical for diagnosing virtual channel mismatch issues in our multi-stream camera application.
2. Specific meaning of status:0x00000004
Additionally, we would appreciate your insight on the specific meaning of the status code 0x00000004 in this context. Is there a documented bitfield or error code mapping for this status value that could help us understand the exact nature of the STREAM_VC error?
System Environment
- Hardware Platform: Jetson AGX Orin 64GB
- Software Version: JetPack 5.1.2 (L4T 35.3.1)
- Kernel Version: 5.10.104-tegra
- Application Scenario: Multi-camera vision system using virtual channels for stream separation
- Thank you for your suggestion regarding increasing the pixel clock frequency (pix_clk_hz) to resolve our CSI interface errors. We have thoroughly tested this recommendation but unfortunately continue to experience the same issues.
Boost the clock to check the trace log if still have “CHANSEL_SHORT_FRAME” that tell the sensor output size less than expected.
log.txt (39.4 KB)
Here is my current log record. My current DTS device tree is as shown in the screenshot below. What should be my next step to find the problem?
Could you please help analyze this? Thank you very much.
Boost the clocks to check if still the same message. You need to consult with sensor vendor for the real output size.
sudo su
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
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/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
cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate
1 Like
Hi Shanecc, I think I made a mistake in the previous DTS configuration. I originally thought Sony’s IMX728 uses two-exposure DOL, but it actually supports dual-gain HDR with a dynamic range of up to 120dB. I’ve now corrected the DTS accordingly.
Currently, I can successfully capture RAW data and achieve normal frame rates, but the following error still persists in the logs:
v4l2-ctl-1897 [005] .... 667.674768: tegra_channel_set_stream: 13e40000.host1x:nvcsi@15a00000- : 0x0
v4l2-ctl-1897 [005] .... 667.674770: csi_s_stream: enable : 0x0
v4l2-ctl-1897 [005] .... 667.687081: tegra_channel_set_power: imx728 2-001a : 0x0
v4l2-ctl-1897 [005] .... 667.687085: camera_common_s_power: status : 0x0
v4l2-ctl-1897 [005] .... 667.704848: tegra_channel_set_power: 13e40000.host1x:nvcsi@15a00000- : 0x0
v4l2-ctl-1897 [005] .... 667.704851: csi_s_power: enable : 0x0
kworker/5:2-143 [005] .... 667.733918: rtcpu_vinotify_event: tstamp:21969220616 cch:0 vi:0 tag:FE channel:0x00 frame:13889 vi_tstamp:703006380736 data:0x0000364100000020
kworker/5:2-143 [005] .... 667.733918: rtcpu_vinotify_event: tstamp:21969220789 cch:0 vi:0 tag:FS channel:0x00 frame:13890 vi_tstamp:703009422304 data:0x0000364200000010
kworker/5:2-143 [005] .... 667.733919: rtcpu_vinotify_event: tstamp:21969220920 cch:0 vi:0 tag:CHANSEL_NOMATCH channel:0x01 frame:13890 vi_tstamp:703009436288 data:0x00000000000006e9
kworker/5:2-143 [005] .... 667.733919: rtcpu_vinotify_event: tstamp:21969558957 cch:-1 vi:0 tag:FE channel:0x00 frame:13890 vi_tstamp:703022534336 data:0x0000000000000020
v4l2-ctl-1897 [004] .... 667.878479: tegra_channel_close: vi-output, imx728 2-001a
kworker/5:3-219 [005] .... 672.718277: rtcpu_string: tstamp:22126703424 id:0x04010000 str:"VM0 deactivating."
Current DTS Configuration:
mode0 { // imx728_MODE_wdr_3840X2160
mclk_khz = "24000";
num_lanes = "4";
tegra_sinterface = "serial_a";
phy_mode = "DPHY";
discontinuous_clk = "no";
dpcm_enable = "false";
cil_settletime = "0";
dynamic_pixel_bit_depth = "12";
csi_pixel_bit_depth = "12";
mode_type = "bayer_wdr_pwl";
pixel_phase = "rggb";
// active_w is the total width of the pixel-active region. In this case, it is:
// 3840 + 4 (LI) + 12 (left margin) + 0 (right margin) = 3856
// active_h is the total height of the pixel-active region. In this case, it is:
// 2160 + 8 (OB) + 6 (Ignored Area Effective Pixel + 50 (VBP)) * 2 = 4448
// active_w = "3856"; //3840
// active_h = "4448"; //2160
active_w = "3840";
active_h = "2160";
// num_of_exposure = "2";
// num_of_ignored_lines = "14";
// num_of_lines_offset_0 = "50";
// num_of_ignored_pixels = "4";
// num_of_left_margin_pixels = "12";
// num_of_right_margin_pixels = "0";
readout_orientation = "0";
line_length = "4448"; //4400
inherent_gain = "1";
mclk_multiplier = "2";
pix_clk_hz = "356400000";// pixel_clk_hz = 891 Mbps × 4 / 10 = 356400000
gain_factor = "10";
min_gain_val = "0"; /* 0dB */
max_gain_val = "120"; /* 12dB */
step_gain_val = "3"; /* 0.3 */
default_gain = "0";
min_hdr_ratio = "16";
max_hdr_ratio = "16";
framerate_factor = "1000000";
min_framerate = "1500000"; /* 1.5 */
max_framerate = "30000000"; /* 30 */
step_framerate = "1";
default_framerate= "30000000";
exposure_factor = "1000000";
min_exp_time = "2433"; /* us */
max_exp_time = "660000"; /* us */
step_exp_time = "1";
default_exp_time = "33334";/* us */
embedded_metadata_height = "0";
/* WDR related settings */
num_control_point = "4";
control_point_x_0 = "0";
control_point_x_1 = "2048";
control_point_x_2 = "16384";
control_point_x_3 = "65536";
control_point_y_0 = "0";
control_point_y_1 = "2048";
control_point_y_2 = "2944";
control_point_y_3 = "3712";
};
The image display is as shown in the attached screenshot.
Could you please help analyze the possible causes of this error? tks
This the dynamic_pixel_bit_depth should be 16 or others more than csi_pixel_bit_depth for PWL HDR.
1 Like
tks
I’ve now modified the DTS to use 16-bit:
mode0 { // imx728_MODE_wdr_3840X2160
mclk_khz = "24000";
num_lanes = "4";
tegra_sinterface = "serial_a";
phy_mode = "DPHY";
discontinuous_clk = "no";
dpcm_enable = "false";
cil_settletime = "0";
dynamic_pixel_bit_depth = "16"; // was 12
csi_pixel_bit_depth = "16"; // was 12
mode_type = "bayer_wdr_pwl";
pixel_phase = "rggb";
active_w = "3840";
active_h = "2160";
readout_orientation = "0";
line_length = "4200"; // was 4400
inherent_gain = "1";
mclk_multiplier = "2";
pix_clk_hz = "456400000";// pixel_clk_hz = 891 Mbps × 4 / 10 = 356400000
gain_factor = "10";
// ... (remaining parameters unchanged)
};
However, after making this change, I encounter the following error during boot:
nvidia@ubuntu:~$ sudo dmesg | grep 728
[sudo] password for nvidia:
[ 1.672861] Bluetooth: Core ver 2.22
[ 7.772845] pva_iommu_context_dev 16000000.pva0:pva0_niso1_ctx2: Adding to iommu group 42
[ 8.172853] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.10
[ 8.249074] imx728 2-001a: probing v4l2 sensor
[ 8.253827] imx728 2-001a: ============== imx728_power_get:
[ 8.266877] imx728 2-001a: Unsupported pixel format
[ 8.271917] imx728 2-001a: Failed to read mode0 image props
[ 8.277689] imx728 2-001a: Could not initialize sensor properties.
[ 8.284055] imx728 2-001a: Failed to initialize imx728
[ 8.289355] imx728 2-001a: tegra camera driver registration failed
[ 8.295798] imx728: probe of 2-001a failed with error -22
[ 8.680728] pci 0001:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 12.917286] systemd[1]: Listening on Journal Socket (/dev/log).
Additional Context:
The configuration for our Sony IMX728 camera involves compressing 20-bit data into a 12-bit HDR3 format. This setup has been successfully used on other SoC platforms. Those platforms only support up to 20-bit and do not support 24-bit PWL decompression, so Sony provided us with this 20-bit HDR3 configuration, which works correctly there.
My Question 1:
I’m now very curious about why, when setting the bit depth to 12-bit, we see cch:-1 appearing in the logs:
kworker/5:2-143 [005] .... 667.733919: rtcpu_vinotify_event: tstamp:21969558957 cch:-1 vi:0 tag:FE channel:0x00 frame:13890 vi_tstamp:703022534336 data:0x0000000000000020
What does a cch value of -1 indicate?
question 2：
kworker/5:2-143 [005] .... 667.733919: rtcpu_vinotify_event: tstamp:21969220920 cch:0 vi:0 tag:CHANSEL_NOMATCH channel:0x01 frame:13890 vi_tstamp:703009436288 data:0x00000000000006e9
- Why does my data show 37?
- 6E9 = 011011101001
- bit 0 = 1;
- bit 1-4 CTYPE = 0100 = 0X4 （LS = 0x4）
- bit 5-10 DTYPE =0011 0111 = 0x37
The csi_pixel_bit_depth must keep 12 for PWL HDR mode.
1 Like
hi ShaneCCC Although we can obtain basic RAW data,
the system logs continuously show the following error:
kworker/5:2-143 [005] .... 667.733919: rtcpu_vinotify_event: tstamp:21969220920 cch:0 vi:0 tag:CHANSEL_NOMATCH channel:0x01 frame:13890 vi_tstamp:703009436288 data:0x00000000000006e9
My question is: Why does the system report channel:0x01? According to my device tree configuration, I have explicitly set the channel to 0, as shown below:
/ {
tegra-capture-vi {
num-channels = <1>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
imx728_vi_in0: endpoint {
vc-id = <0>; // Explicitly set VC ID to 0 here
port-index = <0>;
bus-width = <4>;
remote-endpoint = <&imx728_csi_out0>;
};
};
};
};
host1x@13e00000 {
nvcsi@15a00000 {
num-channels = <1>;
#address-cells = <1>;
#size-cells = <0>;
channel@0 { // Explicitly using channel 0 here
reg = <0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
imx728_csi_in0: endpoint@0 {
port-index = <0>;
bus-width = <4>;
remote-endpoint = <&imx728_imx728_out0>;
};
};
port@1 {
reg = <1>;
imx728_csi_out0: endpoint@1 {
remote-endpoint = <&imx728_vi_in0>;
};
};
};
};
};
};
};
tks
Actually the VC-ID is bit 6:7
It could be incorrect embedded_data_height in your device tree.
| 7 | VC |
|---|---|
| 6 | [1:0] |
| 5 | |
| 4 | STREAM |
| 3 | [5:0] |
| 2 | |
| 1 | (hot |
| 0 | encode) |
1 Like
Thank you for your help. I still have a few questions at the moment and would like to consult you about them , the Sony IMX728 I’m using outputs a single frame of data—the sensor itself has already fused the data internally. However, the fused data is large with a 20-bit depth to->12bit in sensor internally。so requires decompression in PWL mode. There is no need to perform fusion in the ISP of the SoC, so I definitely only have one frame of data. Therefore, I shouldn’t need two channels, and the VC should also be 0. But the log shows that there are two channels of data; since I only have one channel of data, the other channel shows a mismatch. Currently,
my DTS is as follows,
mode0 { // imx728_MODE_wdr_3840X2160
mclk_khz = "24000";
num_lanes = "4";
tegra_sinterface = "serial_a";
phy_mode = "DPHY";
discontinuous_clk = "no";
dpcm_enable = "false";
cil_settletime = "0";
dynamic_pixel_bit_depth = "16"; //12
csi_pixel_bit_depth = "12"; //12
mode_type = "bayer_wdr_pwl";
pixel_phase = "rggb"; // rggb
active_w = "3840";
active_h = "2160";
readout_orientation = "0";
line_length = "4200"; //4400
inherent_gain = "1";
mclk_multiplier = "2";
pix_clk_hz = "456400000";// pixel_clk_hz = 891 Mbps × 4 / 10 = 356400000
gain_factor = "10";
min_gain_val = "0"; /* 0dB */
max_gain_val = "120"; /* 12dB */
step_gain_val = "3"; /* 0.3 */
default_gain = "0";
min_hdr_ratio = "16";
max_hdr_ratio = "16";
framerate_factor = "1000000";
min_framerate = "1500000"; /* 1.5 */
max_framerate = "30000000"; /* 30 */
step_framerate = "1";
default_framerate= "30000000";
exposure_factor = "1000000";
min_exp_time = "2433"; /* us */
max_exp_time = "660000"; /* us */
step_exp_time = "1";
default_exp_time = "33334";/* us */
embedded_metadata_height = "0";
/* WDR related settings */
num_control_point = "4";
control_point_x_0 = "0";
control_point_x_1 = "2048";
control_point_x_2 = "16384";
control_point_x_3 = "65536";
control_point_y_0 = "0";
control_point_y_1 = "2048";
control_point_y_2 = "2944";
control_point_y_3 = "3712";
the log
vi:0 tag:FE channel:0x00 frame:27103 vi_tstamp:593936895232 data:0x000069df00000020
kworker/1:2-158 [001] .... 570.813961: rtcpu_vinotify_event: tstamp:18560796707 cch:0 vi:0 tag:FS channel:0x00 frame:27104 vi_tstamp:593939936864 data:0x000069e000000010
kworker/1:2-158 [001] .... 570.813962: rtcpu_vinotify_event: tstamp:18560796841 cch:0 vi:0 tag:CHANSEL_NOMATCH channel:0x01 frame:27104 vi_tstamp:593939950848 data:0x00000000000006e9
kworker/1:2-158 [001] .... 570.813962: rtcpu_vinotify_event: tstamp:18561810588 cch:0 vi:0 tag:FE channel:0x00 frame:27104 vi_tstamp:593970228032 data:0x000069e000000020
kworker/1:2-158 [001] .... 570.813962: rtcpu_vinotify_event: tstamp:18561810724 cch:0 vi:0 tag:FS channel:0x00 frame:27105 vi_tstamp:593973269632 data:0x000069e100000010
kworker/1:2-158 [001] .... 570.813963: rtcpu_vinotify_event: tstamp:18561810876 cch:0 vi:0 tag:CHANSEL_NOMATCH channel:0x01 frame:27105 vi_tstamp:593973283616 data:0x00000000000006e9
v4l2-ctl-2323 [001] .... 570.865102: tegra_channel_set_stream: enable : 0x0
v4l2-ctl-2323 [001] .... 570.865105: tegra_channel_set_stream: imx728 2-001a : 0x0
kworker/1:2-158 [001] .... 570.873196: rtcpu_vinotify_event: tstamp:18562611957 cch:0 vi:0 tag:FE channel:0x00 frame:27105 vi_tstamp:594003560800 data:0x000069e100000020
kworker/1:2-158 [001] .... 570.873196: rtcpu_vinotify_event: tstamp:18562926095 cch:0 vi:0 tag:FS channel:0x00 frame:27106 vi_tstamp:594006602432 data:0x000069e200000010
kworker/1:2-158 [001] .... 570.873196: rtcpu_vinotify_event: tstamp:18562926226 cch:0 vi:0 tag:CHANSEL_NOMATCH channel:0x01 frame:27106 vi_tstamp:594006616416 data:0x00000000000006e9
kworker/1:2-158 [001] .... 570.873197: rtcpu_vinotify_event: tstamp:18563940283 cch:0 vi:0 tag:FE channel:0x00 frame:27106 vi_tstamp:594036893600 data:0x000069e200000020
kworker/1:2-158 [001] .... 570.873197: rtcpu_vinotify_event: tstamp:18563940414 cch:0 vi:0 tag:FS channel:0x00 frame:27107 vi_tstamp:594039935200 data:0x000069e300000010
kworker/1:2-158 [001] .... 570.873197: rtcpu_vinotify_event: tstamp:18563940565 cch:0 vi:0 tag:CHANSEL_NOMATCH channel:0x01 frame:27107 vi_tstamp:594039949184 data:0x00000000000006e9
v4l2-ctl-2323 [001] .... 570.873202: tegra_channel_set_stream: 13e40000.host1x:nvcsi@15a00000- : 0x0
v4l2-ctl-2323 [001] .... 570.873204: csi_s_stream: enable : 0x0
v4l2-ctl-2323 [003] .... 570.884807: tegra_channel_set_power: imx728 2-001a : 0x0
v4l2-ctl-2323 [003] .... 570.884815: camera_common_s_power: status : 0x0
v4l2-ctl-2323 [003] .... 570.894625: tegra_channel_set_power: 13e40000.host1x:nvcsi@15a00000- : 0x0
v4l2-ctl-2323 [003] .... 570.894628: csi_s_power: enable : 0x0
kworker/1:2-158 [001] .... 570.927721: rtcpu_vinotify_event: tstamp:18565293115 cch:-1 vi:0 tag:FE channel:0x00 frame:27107 vi_tstamp:594084167104 data:0x0000000000000020
v4l2-ctl-2323 [003] .... 571.071582: tegra_channel_close: vi-output, imx728 2-001a
kworker/1:2-158 [001] .... 576.695800: rtcpu_string: tstamp:18745665856 id:0x04010000 str:"VM0 deactivating."
root@ubuntu:/home/nvidia#
Could you please help analyze the cause again tks
Confirm the embedded data to adjust the embedded_data_height.
I have tried modifying many parameters, but it still doesn’t work. Below is the data sheet for my IMX728; what value should I set for
embedded_data_height ?
Please confirm with Sony how many lines of embedded data to set the embedded_data_height.
Hello, I’ve confirmed with Sony that when we use their sensors on other SoCs, we don’t need to set the embedded_metadata_height parameter. Additionally, I added debug prints in vi5.c and found that embedded_metadata_height = 0 . During my debugging process, I tried setting the embedded_metadata_height value from 0 to 80 in the device tree, but it had no effect
printf
desc_memoryinfo->surface[0].size = chan->format.bytesperline * height;
desc->ch_cfg.atomp.surface_stride[0] = bpl;
printk(KERN_INFO "--- imx728 embedded_data_height = %d\n", chan->embedded_data_height);
if (chan->embedded_data_height > 0) {
desc->ch_cfg.embdata_enable = 1;
desc->ch_cfg.frame.embed_x = chan->embedded_data_width * BPP_MEM;
desc->ch_cfg.frame.embed_y = chan->embedded_data_height;
root@ubuntu:/home/nvidia# sudo dmesg | grep 728
[ 7.734975] imx728 2-001a: probing v4l2 sensor 20271202 001 embedded_metadata_height == 80
[ 7.745323] imx728 2-001a: ============== imx728_power_get:
[ 7.752730] imx728 2-001a: tegracam sensor driver:imx728_v2.0.6
[ 7.760379] imx728 2-001a: imx728_board_setup++
[ 7.767844] imx728 2-001a: imx728_power_on: power on
[ 7.774619] imx728 2-001a: imx728_power_off: power off
[ 7.781804] tegra-camrtc-capture-vi tegra-capture-vi: subdev imx728 2-001a bound
[ 7.793054] imx728 2-001a: Detected imx728 sensor
[ 9.892728] hid-generic 0003:046D:C534.0002: input,hiddev96,hidraw1: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-3610000.xhci-4.1/input1
[ 13.880331] imx728 2-001a: ============== imx728_open:
[ 120.098748] imx728 2-001a: imx728_power_on: power on
[ 120.116196] --- imx728 embedded_data_height = 0
[ 120.116220] --- imx728 embedded_data_height = 0
[ 120.116223] --- imx728 embedded_data_height = 0
[ 120.116227] --- imx728 embedded_data_height = 0
[ 120.129963] imx728 2-001a: ==============imx728_set_mode imx728_set_mode:
[ 120.140556] imx728 2-001a: ============== imx728_write_table:
[ 173.384587] imx728 2-001a: imx728: All registers written successfully.
[ 173.391337] imx728 2-001a: imx728_write_reg: i2c write skipped, 0x3012 = f
[ 173.398461] imx728 2-001a: ============== imx728_start_streaming imx728_start_streaming:
[ 173.406900] --- imx728 embedded_data_height = 0
[ 173.406939] --- imx728 embedded_data_height = 0
[ 173.406947] --- imx728 embedded_data_height = 0
[ 173.406952] --- imx728 embedded_data_height = 0
I’m still getting the CHANSEL_NOMATCH error. Besides the embedded_metadata_height value, what other factors could be affecting this mismatch?
kworker/7:1-139 [007] .... 199.488313: rtcpu_vinotify_event: tstamp:6958419948 cch:0 vi:0 tag:CHANSEL_PXL_EOF channel:0x23 frame:54335 vi_tstamp:222666237440 data:0x00000000086f0002
kworker/7:1-139 [007] .... 199.488314: rtcpu_vinotify_event: tstamp:6958420085 cch:0 vi:0 tag:ATOMP_FRAME_DONE channel:0x23 frame:54335 vi_tstamp:222666238016 data:0x0000000000000000
kworker/7:1-139 [007] .... 199.488315: rtcpu_vinotify_event: tstamp:6958420240 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:54335 vi_tstamp:222666240480 data:0x0000000002020311
kworker/7:1-139 [007] .... 199.488315: rtcpu_vinotify_event: tstamp:6958420373 cch:0 vi:0 tag:FE channel:0x00 frame:54335 vi_tstamp:222666349536 data:0x0000d43f00000020
kworker/7:1-139 [007] .... 199.488316: rtcpu_vinotify_event: tstamp:6958420526 cch:0 vi:0 tag:ATOMP_FE channel:0x00 frame:54335 vi_tstamp:222666349568 data:0x0000000800000000
kworker/7:1-139 [007] .... 199.488316: rtcpu_vinotify_event: tstamp:6958420660 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:54335 vi_tstamp:222666354592 data:0x0000000000020311
kworker/7:1-139 [007] .... 199.488316: rtcpu_vinotify_event: tstamp:6958420812 cch:0 vi:0 tag:FS channel:0x00 frame:54336 vi_tstamp:222669391168 data:0x0000d44000000010
kworker/7:1-139 [007] .... 199.488317: rtcpu_vinotify_event: tstamp:6958420944 cch:0 vi:0 tag:ATOMP_FS channel:0x00 frame:54336 vi_tstamp:222669391168 data:0x0000000800000000
kworker/7:1-139 [007] .... 199.488317: rtcpu_vinotify_event: tstamp:6958732023 cch:0 vi:0 tag:CHANSEL_NOMATCH channel:0x01 frame:54336 vi_tstamp:222669405152 data:0x00000000000006e9