About csi_trace log

I recently encountered an issue where I found that I couldn’t get the first frame of sensor output. After checking the CSI log, I noticed that it consistently reported the following error. Could you help me understand the specific meaning of this log?

tag:CSIMUX_STREAM channel:0x00 frame:3072 vi_tstamp:963544573920 data:0x0000000000100000

It tell SPURIOUS DATA. That could be sensor output un-support user-defined data type.

Thank you for your response. I have a few more questions to understand:

  1. Why is “frame:3072” appearing? Is it normal for it to be 3072, which is the height of my image? Shouldn’t it be “frame:1” in normal circumstances?
  2. Based on your answer, could it be possible that there is an issue with parsing my first frame of data? For example, data that should represent the datatype is actually storing other data, causing NVCSI to recognize it as an unsupported datatype. Consequently, what should have been “WC[word-count:3072]” is recognized as a frame ID. Is this a likely scenario?

the csi_trace log:
log2.txt (115.2 KB)

What does this log about PHY specifically indicate?

     kworker/4:1-55      [004] ....   922.601315: rtcpu_nvcsi_intr: tstamp:29575762525 class:GLOBAL type:PHY_INTR0 phy:3 cil:0 st:0 vc:0 status:0x60000000
     kworker/4:1-55      [004] ....   922.601316: rtcpu_nvcsi_intr: tstamp:29575762525 class:GLOBAL type:PHY_INTR0 phy:3 cil:1 st:0 vc:0 status:0x20000000

The key could be CHANSEL_NOMATCH that could be incorrect embedded_data_height in device tree.

     kworker/4:3-199     [004] ....   789.061013: rtcpu_vinotify_error: tstamp:25401718470 cch:-1 vi:0 tag:CHANSEL_NOMATCH channel:0xe0 frame:4 vi_tstamp:812854944768 data:0x0000000000000569

Your response has left me somewhat confused. I need to restate my question. The situation is this: after powering on the sensor for the first time, I cannot receive the first frame of the image, but I can receive images from the second frame onwards. I can confirm that there are no configurations related to embedded data in both the sensor and the device tree. My issue is not related to this. I want to understand what is causing Orin not to decode the first frame of the image.thank you

OK, that could be the first frame send out before the NVCSI start captrue.

Thanks

I don’t think this is the reason causing it. We have previously considered this possibility and conducted some experimental attempts, such as adding a delay before enabling the sensor output, or enabling sensor output after starting V4L2 streaming to ensure that the first frame is sent out after NVCSI starts capturing. However, we still encountered the same error with the same logs. So, are there any other possibilities we should explore? thanks

How do you know lose the first frame?
What’s the BSP version?

I checked the frame-id (also called frame-number or frame count),The frame ID is decoded from the MIPI signal, and it should start counting from 1. However, what I’m getting starts from 2, just as shown in the logs. The logs after frame:2 are normal, and by calculating the frame time from the second frame’s FS time point backward in the logs, it coincides with the error message “CSIMUX_STREAM,data:0x0000000000100000” at the time of the first frame’s FS. So, I believe the first frame wasn’t received correctly
We have tested this on both the R35.5.0 and R35.3.1 versions of the BSP

Could you verify by delay the sensor streaming on to check if able get the first frame?

We have tried similar operations, such as delaying the activation of the sensor output register, but still cannot obtain the first frame of the image.
The process looks something like this: write sensor ini register without stream on–> open /dev/video0 → start to capture → write sensor stream on register.

Is this still an issue to support? Any result can be shared?