Picture through HDMI to LT6911C then input the TX2 MIPI CSI port,Probabilistic cannot read valid image information (green screen).We used an HDMI-MIPI bridge chip, which converted the HDMI input signal to the MIPI signal, and modified the driver based on OV5693.Trace the kernel print information, as shown below Please help thanks:trace.log (515.4 KB)
you may refer to below kernel sources and device tree which support Toshiba UH2C/D HDMI-CSI bridge driver on TX2.
usually there’s test-pattern-generator on the HDMI-MIPI bridge chip; you can enable that to verify the connection and also narrow down the issues.
according to your 1st image about the trace logs, it looks VI engine receive frames and also got the timestamps. could you please share the trace logs with kernel report syncpt timeout failures?
thank for your reply,
about the first and second points, because the LT6911 chip we used has an internal controller, no need to go through the I2C configuration the related information,
about point three,how can I get the trace logs with kernel SyncPT Timeout failures?
and we are currently use for migration and development was based on L4T-28.2.1, and do not know whether this will have an impact this. thanks
please refer to below to enable the tracing logs from debugfs. you should enable tracing logs and then enable camera to gather all details.
echo 1 > /sys/kernel/debug/tracing/tracing_on echo 30720 > /sys/kernel/debug/tracing/buffer_size_kb echo 1 > /sys/kernel/debug/tracing/events/tegra_rtcpu/enable echo 1 > /sys/kernel/debug/tracing/events/freertos/enable echo 2 > /sys/kernel/debug/camrtc/log-level echo > /sys/kernel/debug/tracing/trace cat /sys/kernel/debug/tracing/trace
you can keep in l4t-r28.2.1 if you’re able to make your use-case works normally.
suggest to have software release upgrade (i.e. l4t-r32.4.x) for better software supports.
thanks for your help, below its the tracing log trace01.log (237.1 KB)
it looks like you’re able to enable sensor stream for several times,
here’re messages to indicate correct steaming sequence,
... rtcpu_vinotify_handle_msg: tstamp:10728120352 tag:CHANSEL_PXL_SOF channel:0x01 frame:10283 vi_tstamp:2138185221 data:0x00000001 rtcpu_vinotify_handle_msg: tstamp:10728120537 tag:ATOMP_FS channel:0x01 frame:10283 vi_tstamp:2138185231 data:0x00000000 rtcpu_vinotify_handle_msg: tstamp:10728123768 tag:CHANSEL_LOAD_FRAMED channel:0x01 frame:10283 vi_tstamp:2138188763 data:0x18000000 rtcpu_vinotify_handle_msg: tstamp:10729120092 tag:CHANSEL_PXL_EOF channel:0x01 frame:10283 vi_tstamp:2139185064 data:0x04370002 ...
it turns out short frame errors in your last trial.
rtcpu_vinotify_handle_msg: tstamp:18699244495 tag:CHANSEL_SHORT_FRAME channel:0x10 frame:7506 vi_tstamp:1519374699 data:0x00000001 rtcpu_vinotify_handle_msg: tstamp:18699244670 tag:ATOMP_FE channel:0x00 frame:7506 vi_tstamp:1519374702 data:0x00000001
short frame errors means the image sensor outputs a smaller frame as the one registered through the V4L2 driver.
please review your sensor driver configuration,
also, could you please refer to external page and apply camera patches for R28.2.1 release.
新建文本文档.txt (8.2 KB) Hi Jerry：
The following(.txt) is the device tree information for our sensor, where the embedded_metadatA_height default value is 0 and has not changed since modification.the below jpg file its our log
2: Data Error of CSI Camera Capture on Jetson TX2, Does this solution can apply to my situation?
3: CHANSEL_SHORT_FRAME error which parameter needs to be changed?
Please help check,thanks
- please review your sensor signaling, please set embedded_metadata_height=0 if there’s no embedded data line.
- we fixed some camera driver issues, and there’re patches available; please go ahead to apply them for a try.
- in VI drivers, it use line and frame to indicate horizontal and vertical signaling; please adjust active_h to resolve short frame errors.
After updated the patch,verification, there is still a chance when open the device will show the green screen,the below is the log and kernal，any other suggestion for this,thanks a lot
please share the commands or gst pipeline for reference, also, may I know your failure rates?
We use the 12_camera_v4l2_cuda, command#：./camera_v4l2_cuda -d /dev/video1 -f UYVY -s 3840x2160 -n 30 -c；
The failure rate is about 5%, we set the program to boot automatically, based on the performance of the program at each startup,
please enable v4l2 standard controls to narrow down the issue, this should only access camera streaming.
$ v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=UYVY --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100
in the meanwhile,
please also examine the drivers of your HDMI-MIPI bridge chip; please confirm whether it’s still sending frames while the issue repo’ed.