We want to capture from a Sony IMX264 sensor using the Lattice MACHX03 SUB_LVDS to CSI2 MIPI bridge. Initially, we do not use the image sensor, but instead tries to capture the colorbar test pattern generated by the FPGA. However, this fails with the following log messages:

kworker/0:0-1973  [000] ...1  3376.365537: rtcpu_vinotify_handle_msg: tstamp:105842355114 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:2763139570 data:0x00000001
     kworker/0:0-1973  [000] ...1  3376.365538: rtcpu_vinotify_handle_msg: tstamp:105842709868 tag:CHANSEL_PXL_SOF channel:0x00 frame:0 vi_tstamp:2763493997 data:0x00000001
     kworker/0:0-1973  [000] ...1  3376.365539: rtcpu_vinotify_handle_msg: tstamp:105842710056 tag:ATOMP_FS channel:0x00 frame:0 vi_tstamp:2763494004 data:0x00000000
     kworker/0:0-1973  [000] ...1  3376.365540: rtcpu_vinotify_handle_msg: tstamp:105842710196 tag:CHANSEL_FAULT channel:0x00 frame:0 vi_tstamp:2763494206 data:0x00000200
     kworker/0:0-1973  [000] ...1  3376.365541: rtcpu_vinotify_handle_msg: tstamp:105842711019 tag:CHANSEL_LOAD_FRAMED channel:0x01 frame:0 vi_tstamp:2763495238 data:0x08000000
     kworker/0:0-1973  [000] ...1  3376.365542: rtcpu_vinotify_handle_msg: tstamp:105842711150 tag:CHANSEL_FAULT_FE channel:0x01 frame:0 vi_tstamp:2763495243 data:0x00000001
     kworker/0:0-1973  [000] ...1  3376.365543: rtcpu_vinotify_handle_msg: tstamp:105842711312 tag:ATOMP_FE channel:0x00 frame:0 vi_tstamp:2763495246 data:0x00000000

Based on the payload of the CHANSEL_FAULT message the error is “PIXEL_SHORT_LINE”, but the line length is set according to the output from the FPGA. Regardless of what value we set the line length to the error still remains. We believe that this has something to do with the CSIMUX_STREAM error. How can we debug the root cause of the CSIMUX_STREAM error and what does it mean? The documentation is quite sparse on this specific error code.

The you have to check the sensor output width instead of line length. You can try modify the sensor driver to decrease the width to try.

Have you set the width in your driver and the ‘active_w’ property in the device tree?

Yes I did set the width and active_w values according to the specified test pattern dimension in the FPGA colorbar generator. However, by trial and error, I have found that the actual output from the FPGA is of another width and height than specified. Now I can successfully capture the colorbar image using v4l2-ctl without any vi errors. I assume the CSIMUX_STREAM error is a generic error that is not directly useful for debugging.

Error free log messages is embedded below:

kworker/4:1-115   [004] ...1   943.943170: rtcpu_vinotify_handle_msg: tstamp:29829511141 tag:CHANSEL_PXL_SOF channel:0x00 frame:0 vi_tstamp:4059706826 data:0x00000001
     kworker/4:1-115   [004] ...1   943.943172: rtcpu_vinotify_handle_msg: tstamp:29829511300 tag:ATOMP_FS channel:0x00 frame:0 vi_tstamp:4059706832 data:0x00000000
     kworker/4:1-115   [004] ...1   943.943175: rtcpu_vinotify_handle_msg: tstamp:29829513409 tag:CHANSEL_LOAD_FRAMED channel:0x01 frame:0 vi_tstamp:4059709217 data:0x08000000
     kworker/4:1-115   [004] ...1   943.943177: rtcpu_vinotify_handle_msg: tstamp:29829666621 tag:CHANSEL_PXL_EOF channel:0x00 frame:0 vi_tstamp:4059862135 data:0x01f20002
     kworker/4:1-115   [004] ...1   943.943179: rtcpu_vinotify_handle_msg: tstamp:29829666743 tag:ATOMP_FE channel:0x00 frame:0 vi_tstamp:4059862534 data:0x00000000

Hi @pp28bgsbm,
I’m having a similar problem. How did you get the actual output size of your FPGA? Was it specified somewhere? Thanks!

Unfortunately, the part of the FPGA handling the output is a blackbox module, so I had to guess the output dimensions. When capturing with v4l2-ctrl you can find the correct dimension by looking at the dmesg log and using the following rules for interpreting the errors:

  • CHANSEL_SHORT_FRAME = The specified frame height is not correct
  • CHANSEL_FAULT 200 = The specified frame width is too large
  • CHANSEL_FAULT 100 = The specified frame width is too small

I recommend starting with finding the correct height, and then the width afterwards. Note that if you capture with v4l2 in C++, then the dimensions of the frame might have changed again. In my case the sensor (IMX264) outputs images in the format 2464x2066, but the FPGA changes that to 2476x2066, and finally, the frame buffer available in v4l2 has the size 2496x2066.

Somehow, the CHANSEL_SHORT_FRAME has been solved by correcting the frame format, as I was generating RAW8 formatted frames in the FPGA and capturing them in RG10. So I changed it to RAW10, and now that error dissappeared, remaining only the CSIMUX_STREAM error, which has probably nothing to do with this. So, in my case, I’d say that the actual output may be equal to the one specified in the FPGA, as I’m not getting that error anymore. Thanks for your response anyway!