i.MX6 IPU CSI capture via IC fails with IC_ENC_FRM_LOST_ERR

[baruchsiach]

Hi i.IMX community,

I'm trying to capture a video stream on the i.MX6 SABRE Smart Devices board from IPU CSI via IC and IDMAC (channel 20) to RAM. I'm using a slightly modified version of the OV5640 driver that makes the camera stream the frames in RGB format. I'm configuring the IC encoder task to convert from RGB to YUV for later processing by the VPU.

This setup works nicely under Linux. My target OS however is GHS Integrity. I can capture raw RGB frames when I use the SMFC and IDMAC (channel 0). But whenever I enable the IC encoder I see no EOF interrupt, but the IC_ENC_FRM_LOST_ERR status bit (INT_STAT_10) turns on.

Now before anyone asks, I know that the OV5640 camera can give me YUV directly. But my target application must support both YUV and RGB CSI capture. So I'm trying to simulate RGB capture on the SABRE Smart Devices board. I must convert the data to YUV since the VPU encoder only supports YUV input.

I verified that the configuration of ALL IPU registers is identical in both Linux and Integrity. I actually dumped the entire registers address space to be sure.

I would appreciate if anyone can shed some light on this IC_ENC_FRM_LOST_ERR status bit, or provide any other help.

Thanks,

baruch

[baruchsiach · Accepted solution]

Hi i.MX community,

Just to answer my own question: one of IPUx_CH_BUFx_RDY0 bits for channel 20 must be enabled. Otherwise the IC_ENC_FRM_LOST_ERR error is asserted. For some reason SMFC work anyway, but IC does not.

One more thing: double buffering must be enabled in IDMAC. Single buffer doesn't work.

baruch

[Yuri]

Hello,

  From section 38.4.12.3 (Interrupt Generator) of the i.MX6 DQ Reference Manual :

The table below describes the error interrupts. The panic column indicates if

this signal is part of the logic generating the ipu_panic signal. The ipu_panic

signal can be used for indicating about errors that are result of data rate

1. problems. Such problems may be a result of the IPU running in slower clock then

required by the use case. This signal can be used in order to indicate the

system that the IPU can't handle the desired data rate. In that case the system

may need to increase the clock to the IPU or simplify the use case.

   So, looks like we have here performance problem. Please try to decrease screen

resolution and / or frame rate. Also, other system resource consuming processes,

such as USB / SD / SATA transfer, may affect. As result a general performance

issue may take place in the case.

Perhaps it makes sense to try system prioritization (such as provided by Linux

nice command).

Also, You may refer to the next thread :

Re: To find the root cause of i.MX6Q IPU error interrupt. 

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[baruchsiach]

Hi Yuri,

Thanks for your answer.

The capture data rate the I am testing is very low, 640x480@20fps. Just to test this theory I further reduced fps to ridiculously low 10fps (by tweaking OV5640 register 0x3036), but the same error persists. Under Linux I have no problem capturing at the original rate.

The video capture test task is the only actively running task in the system, so I would not suspect resources shortage.

Do you have any other suggestion?

Thanks again,

baruch