Is there a limitation on the number of captured frames over MIPI CSI-2 on i.MX 8M Mini?

[marius-a]

Hi,

We are using vendor board based on i.MX 8M Mini SoC with MIPI CSI-2 image sensor. Sensor is set to trigger mode where external input signal is used to start exposure and readout. What I have observed is that if the number of captured frames between V4L2 capture start and stop is even then the following capture is working as expected. If the number of captured frames is odd then the first sensor trigger of the next capture sequence causes CSI bridge interrupt where BASEADDR_CHHANGE_ERROR bit is set in CSI_SR and neither DMA_TSF_DONE_FB1 nor DMA_TSF_DONE_FB2 bits are ever set. The following frames are captured as expected.

For reference, we are using NXP kernel version 5.15.71 with some board vendor patches (based on linux-imx, branch lf-5.15.y). Yavta is used for frame capture over V4L2.

Is it a known limitation that the number of captured frames must be an even number for the following capture to work correctly? I suspect that some internal state is retained (frame buffer index left at FB2?) which causes an extraneous BASEADDR_CHHANGE_ERROR interrupt and DMA transfer to never complete. Is there a way to reset CSI bridge properly?

I believe the issue could also be reproduced when sensor is set to free-run mode. I am almost always getting BASEADDR_CHHANGE_ERROR bit set for the first interrupt using Yavta when it is run for a second time.

[joanxie]

do you mean skip the first frame, then The following frames are captured as expected, right? refer to the reference manual, A Base Address change error is generated when the base address changed while the last frame data transfer are not finished.

[marius-a]

Yes, the first frame never arrives, BASEADDR_CHHANGE_ERROR is set and the following frames are captured as expected. The problem is that it only happens when the number of captured frames from the previous sequence (between VIDIOC_STREAMON and VIDIOC_STREAMOFF ioctls) is an odd number. I do not see why DMA transfers would not complete only in those specific cases and the behavior is stable and can be easily reproduced.

I can also add that the issue can be resolved by not setting BASEADDR_SWITCH_EN bit in CSI_CR18 register but we prefer to have frame buffers synchronized with vsync for better resilience against corrupt frames.

[joanxie]

mailed to you already, pls check it

[joanxie]

I don't the you receive the mail or not, I post here again, it seems this issue is related EOF trigger,

refer to the RM, "Software sets the RX count register to the frame size (in words).If the preset value is reached, an EOF interrupt is generated and the data in the RXFIFO are read. If a SOF event is detected before this happens, the EOF interrupt is not generated. " it seems the counter value is larger then the one frame size so the SOF event is detected before generate EOF interrupt, then CSI skip the first frame

and refer to the register CSI_RXCNT, This is a 22-bit counter, you can double check this register when you use odd number frames