MT9M021: Error while attempting capture using gstreamer and nvgstcapture

Autonomous Machines Jetson & Embedded Systems Jetson TX1
21

Hi EV,

Since we don’t have adapter board to connect our LI-M021C-MIPI to TX1 yet, we don’t have the driver right now, but we have a customer (NovaDynamics) who successfully get the LI-M021C-MIPI camera working on TX1 platform. Please check the code in link below as an reference. They are happy to share the code with our other customers.
[url]https://github.com/DaxBot/daxc02[/url]

22

Hi Simon,

We’ve looked at the way Nova worked through their driver issues, but the same process hasn’t worked for us yet. We do get images using v4l2 and yavta, but gstreamer crashes. We could send you the CTI equipment, an Elroy carrier and adapter board, if you would be able to try to help out.

23

Hi somerled,

We would like to help you on this, but normally, we only do the debug for Nvidia EVA board and our own carrier board. For other carrier boards, it may take lots of time to review the design schematics and other documents. It is not efficient for us to do that. It will be better the board designer to debug the board. At the same time, our team will post the comments if they have any suggestions on the issues.

24

I managed to get the daxco2 code detect the chip on our BSP, but gstreamer returns the same error.
Attached are the logs. Are we missing some fixes in gstreamer or nvgstcapture? From the forum which was mentioned in my previous comment, it looks like there were some variants of library files that were exchanged.

Attachments: terminal logs and dmesg logs
runlog.txt (7.94 KB)
dmesg.log (114 KB)

25

Hi EV，

You mean V4L2 was able to capture the sensor RAW image, that is to say TX1 CSI2 interface works well for receiving M021 input MIPI image data, and the sensor board also works well.

Gstreamer and Argus APP capture the YUV data that generated by TX1 ISP, so it may be the ISP not work well, I think you can do the following step to have a check:

  1. If you load the Argus or Gstreamer APP, check if the ISP interrupt is generated.
  2. If the ISP generates interrupt, I think the Gstreamer and ARgus program have problem, if there is no ISP interrupt, the ISP may not work well.
  3. Check if you have modified any ISP parameter in the kernel device tree file.
  4. Check your carrier board schematic, maybe some pin you modified from NVIDIA EVA, which effects the ISP.
26

Hi Wing Hu,

Yes. Looks like an issue either with gstreamer or the ISP.
Can you please elaborate the test procedure to check for ISP interrupt. Sorry but I haven’t worked with gstreamer before.

We haven’t modified any ISP related parameter in the kernel. But, we had to modify the T_HS_ZERO parameter so as to get rid of the channel error issue we were facing earlier.

We will look into the schematic to see whether the changes could affect ISP in some form.
I hope someone could help us look at the logs I attached and understand the issue clearly. It is still unclear what the reason for the crash is.

Thanks

27

We haven’t been able to figure out the reason for GStreamer crash yet. To reiterate, we observe right after attempting to start capturing. I hope someone could help us look at the logs and find out the reason for this crash.
Thanks
runlog.txt (7.94 KB)
dmesg.log (114 KB)

28

Can you help with this error that seems to be related to interlace mode?

The command attempted was:

gst-launch-1.0 --gst-debug-level=2 -vvv v4l2src num-buffers=10  ! 'video/x-bayer, width=(int)1280, height=(int)720, format=(string)rggb, framerate=(fraction)30/1' ! multifilesink location=test%d.raw  -v

The debugging output included this message:

0:00:00.161199759  2290       0x5aa1e0 ERROR                   v4l2 gstv4l2object.c:1873:gst_v4l2_object_get_interlace_mode: Driver bug detected - check driver with v4l2-compliance from http://git.linuxtv.org/v4l-utils.git