Embedded data causes CHANSEL_NOMATCH?

Hi,
I’ve been modifying my driver for isx021 camera sensor to get Embedded data on Xavier DevKit + Leoaprd Camera kit on R35.1.

A year and a half ago, I could get the camera image including the front embedded data as data type 0x1E on L4T R32.5.1 with “embedded_metadata_height = 0” in DTB.
But now can not get it on R35.1. I got the camera image of which the last line was green and which was stucked.

The trace log says like “CHANSEL_NOMATCH channel:0x01 frame:0 vi_tstamp:125752529472 data:0x00000000000003c9”. Does this mean data type is 0x1E and at LS ? I think the front embedded data is recevied, but the stream id or vi channel is wrong.

Does channel:0x01 mean the data comes with vc=0 and from csi port = 1 ? I would like to get the data causing CHANSEL_NOMATCH, how can I get the data ? Is it impossible ?

ISX021 is able to set any data type for embedded data and and output it with camera image data. In order to get front and rear embedded data, I set the data type to 0x1E as same as the image data to create one image with data type 0x1E including the embedded data, and customer applications will get the both embedded data by extractiong them from the camera image data.

Test procedure

One camera is connected to port1.

  1. mode1(WxH:1920x1281, embedded_metadata_height=0) is added to camera sensor node in DTB because the front embedded data is consists of 1 line.
  2. Set up ISX021 camera sensor for outputting the front embedded data by setting data type to not 0x12 but 0x1E.
  3. Run gstreamer with mode1(WxH:1920x1281) instead of mode0(1920x1280)

Thanks.

dmesg.log (83.5 KB)
trace.log (241.9 KB)

The channel:0x01 means stream:1 vc:0

7 VC
6 [1:0]
5
4 STREAM
3 [5:0]
2
1 (hot
0 encode)

The trace log also see the CHANSEL_SHORT_FRAME at beginning that tell the lines less than expected.

Thanks, ShaneCCC

I set the cmaera sensor to mode1(1920x1281), and the camera sensor sends the image data (1920x1280)without front embedded data(1 line) for a while because the sensor needs time to prepare the embedded data. So CHANSEL_SHORT_FRAME appears for a while after starting streaming and disappears after a few hundreds ms.

I think the stream id is wrong and should be 0 because it is derived from port-index=0 (for the ports on J1 connector) in DTB. “port-index = 1” does not exist in my DTB . I don’t know what is the cause of “stream id = 1”.

Additional information.

I am able to get the correct camera image and the embedded data. I have chekced the embedded data by the test code which got the whole image data including the embedded data and extracted them from the image data.
when two cameras are connected to the same Des(max9296) and start streaming on the camera on port 1 only, it works well in this case only. It does not work in the case of starting streaming on the camera on port 2 only. The driver codes and DTB are the same for any case.

For that I would suspect it could be the Des(max9296) configuration cause it. How about connect to Xavier directly without SER/DESER ?

Though I thought Des caused this issue first, I think it is not so. Des is unable to affect stream id which depends on the port of CSI core connected to the Des.
And my driver and DTB(only active_h is different) works fine without the embedded data in all cases of one or two cameras connected to the same Des with the same configuration for embedded data.

And I have one question about the diagram at “Port Index” in the Driver Developer Guide below.
https://docs.nvidia.com/jetson/archives/r35.1/DeveloperGuide/text/SD/CameraDevelopment/SensorSoftwareDriverProgramming.html

I circled “x4” in red, but I don’t understand the meaning of the downward arrow. Does it mean that the x4 lane data is split across two “x2 lanes” (CSI A&B ports)?

my overlay DTS.
shdq3-isx021-gmsl-device-tree-overlay-xavier-devkit-r351.dts (62.8 KB)

Thanks

Right

What the log if set embedded_metadata_height=1 for the same configure?

ShaneCCC
I appreciate for you advices.

This issue is solved. I should have thought of channel as just a channel number, not related to CSI ports.

At first, the camera image without embedded data came to CSI port 0 and assigned to vi channel 0x00, which caused CHANSEL_SHORT_FRAME because it lacked one embedded data line. And this channel:0x00 is kept opened. After a few hundreds milli-seconds, the camer image with the embedded data came to the same CSI port. But channel 0x00 is already assigned to the last image data, then another channel(0x01) is assigned to the new image data with the embedded data.Therefore I modfied the driver code not to output the camera image without the embedded data.

At last, I got the camera image including the embedded data for case of one camera connected to one Des and two camera connected to the same Des.

Thanks.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.