The Parker TRM describes several NOTIFY tags from the VI which can by enabling teh tegra_rtcpu trace events. In section 27.6.2 is mentions that the payload of CSIMUX_FRAME and CSIMUX_STREAM events ctonains the stream ID and any “appropriate errors, as described above”. The errors themselves are indeed describes in 27.6.1.2, but no value is ascribed to each.
I am currently failing to get nvcamerasrc to work with my camera driver, while direct v4l2 capture is working fine. I am getting errors such as the following:
kworker/0:0-2057 [000] ...1 2719.317627: rtcpu_vinotify_handle_msg: tstamp:85284674839 tag:CSIMUX_FRAME channel:0xac frame:2832 vi_tstamp:3680295769 data:0x00000400
kworker/0:0-2057 [000] ...1 2719.317628: rtcpu_vinotify_handle_msg: tstamp:85284675546 tag:CHANSEL_FAULT channel:0x00 frame:2832 vi_tstamp:3680295769 data:0x00670200
Have I overlooked the definition in the TRM, or is this documented somewhere else?
Hi
You mean you can capture by v4l2-ctl and failing on gst-launch-1.0 command? Have you check the raw image from the get by v4l2-ctl is normal? Does any PXL_SOF timeout kernel message?
Correct: Using v4l2-ctl I can capture raw (10-bit BGGR) frames at full rate with no errors. The NOTIFY tags from that look like:
kworker/4:2-340 [004] ...1 166.236926: rtcpu_vinotify_handle_msg: tstamp:5501384774 tag:CHANSEL_PXL_SOF channel:0x00 frame:3173 vi_tstamp:1206417045 data:0x00000001
kworker/4:2-340 [004] ...1 166.236928: rtcpu_vinotify_handle_msg: tstamp:5501385097 tag:ATOMP_FS channel:0x00 frame:3173 vi_tstamp:1206417048 data:0x00000000
kworker/4:2-340 [004] ...1 166.236930: rtcpu_vinotify_handle_msg: tstamp:5501388020 tag:CHANSEL_LOAD_FRAMED channel:0x01 frame:3173 vi_tstamp:1206420393 data:0x08000000
kworker/4:2-340 [004] ...1 166.236931: rtcpu_vinotify_handle_msg: tstamp:5501504705 tag:ATOMP_FE channel:0x00 frame:3173 vi_tstamp:1206537045 data:0x00000000
Viewing the frames on my desktop I can see a clear scene (acknowledging that the 10-bit input is being stored as 16-bit with replicated bits as per TRM section 27.10.6).
Using gst-launch-1.0 (nvcamerasrc) results in the messages in #1, and yes there is also a corresponding PXL_SOF timeout. The timeout (in this case) is due to the ISP not processing any frames. The reason why is what I’m trying to figure out, and I suspect the payload of the CSIMUX_FRAME tag can help point me in the right direction.
For the nvcamerasrc you need to make sure all mclk_khz, mclk_multiplier, pix_clk_hz, discontinuous_clk are correct.
mode0 { // OV5693_MODE_2592X1944
mclk_khz = "24000";
num_lanes = "2";
tegra_sinterface = "serial_c";
discontinuous_clk = "no";
dpcm_enable = "false";
cil_settletime = "0";
active_w = "2592";
active_h = "1944";
pixel_t = "bayer_bggr";
readout_orientation = "90";
line_length = "2688";
inherent_gain = "1";
mclk_multiplier = "6.67";
pix_clk_hz = "160000000";
min_gain_val = "1.0";
max_gain_val = "16";
min_hdr_ratio = "1";
max_hdr_ratio = "64";
min_framerate = "1.816577";
max_framerate = "30";
min_exp_time = "34";
max_exp_time = "550385";
};
Forum Admin: I have undone the accepted answer. This post’s question has NOT been answered yet. The answer is either the definition of the payload bytes for the NOTIFY messages, or an acknowledgement that the documentation is not public.
Please check the TRM chapter 21 video input (VI) for below information.
CHANSEL_PXL_SOF
ATOMP_FS
CHANSEL_LOAD_FRAMED
ATOMP_FE
I’m reading the Parker TRM (TX2, yes?), Video Input is chapter 27. The most detail I’ve found for the definition of the payload is in 27.14.2 for CSIMUX_FRAME: (Emphasis mine)
If I continue searching for the word payload, I eventually come across a list of values that are not in any sub-chapter, but simply appended at the very end of chapter 27.20 immediately following the last register definition:
So it seems I half the of my original post’s answer, but I have not found a definition for CHANSEL_FAUL yet. Am I missing it somewhere?
It means pixel_short_line detected on line_number = 103
103 = 16bit MSB of the playload data
kworker/0:0-2057 [000] ...1 2719.317628: rtcpu_vinotify_handle_msg: tstamp:85284675546 tag:CHANSEL_FAULT channel:0x00 frame:2832 vi_tstamp:3680295769 data:0x00670200
Ah, thank you! For CHANSEL_FAULT, is [31:16] always “line_number”? How about the lower 16 bits? And most importantly: Is this in the TRM somewhere that I’ve missed?
Awesome! Thank you so much ShaneCCC :-)
Now that we know there is a pixel_short_line error, can anyone provide an idea as to why this would happen when using nvcamerasrc and why we can capture using v4l2-ctl with no errors?
@jenslin
Did you check the data is validate from v4l2-ctl? pixel_short_line means sensor output width is not as expect as the active_x, check the value of device tree and sensor driver is sync or not.