DM3730 EVM and OV14810

Section 2.1.4 of Mistral's EVM manual states "the camera interface signals are routed by default to expansion connector."  The manuals says this is controlled by T2_GPIO2 being set high (table 5).  We are having the opposite problem.  We want to use the TVP5146 to decode composite video in, and can't figure out how configure it for that.  Let me know if you have any insight.

THX

I have gotten the video input to "work", but now I get the following error while it is running.  I am able to capture several video frames prior to this message appearing.

omap3isp omap3isp: omap34xx_isp_isr: sbl overflow, sbl_pcr = 00400000

Any advice on how to debug this issue or what might be causing the sbl overflow?  The TRM states that the error is " RESIZER line 2 write-buffer memory overflow".

I am also integrating the OV14810 sensor with a DM3730 EVM and I'm getting the same exact issue.  Have you been able to solve this?  Can anyone from TI comment on the problem?

Thanks,

Jason

Jason,

I have not been able to solve this issue yet, though I have had some success by adjusting the .pixelclk field of the isp_interface_config structure. 

Have you been able to get a stable image from the OV14810?  I would be very interested to see your kernel/driver modifications.  I have been spinning my wheels trying to get a clean image (I started with the OV3640 driver and have been trying to just get minimal video capture).   Is there any way you could share your driver here?

Thanks,

Jeff

Jeff,

I have gotten a stable image from the OV14810 in VGA and 720p mode.  This driver is based of the Leapord Imaging driver for the mt9t111 and it includes some hacks but hopefully the attachment might be of some help to you.  Ignore the stuff about CSI2 mode - we tried that and never got it working.  Also note that I'm working with the version of the kernel (2.6.32) that comes with the latest DVSDK for DM3730 so if you're working with any other kernel version this probably won't help you.

Good Luck

- Jason

Thank you Jason.  I am also using the DVSDK so the code you attached was very applicable.  I have started comparing it to what I have and the two are looking very similar. 

To clarify my statement about the pixel clock settings, I found in the DM3730 TRM (May 2011 version) on page 1261:

 Video Port
The 10-bit video-port output is enabled with CCDC_FMTCFG[15] VPEN = 1. Because the input data can
be up to 12 bits, one must select which 10 bits are selected with CCDC_FMTCFG[14:12] VPIN.
The output of the video port goes to the Preview module. At the output of the video port, the data rate is
resynchronized; the CCDC_FMTCFG[21:16] VPIF_FRQ bit field selects the video-output data rate as: L3
speed/(CCDC_FMTCFG[21:16]VPIF_FRQ + 2) (from L3 speed/ 2 MHz to L3 speed/8 MHz). If
CCDC_FMTCFG[21:16] VPIF_FRQ frequency is set too low compared to the input pixel clock, overflow
can occur.

So I believe that is why lowering the input pixel clock (using the OV14810 clock dividers) fixed the overflow problem.  So you might try changing the value of the VPIF_FRQ in order to keep your pixel clock settings.  I have not tried this yet, let me know if it helps.

The value should default to 0 which the TRM states on page 1281 is equal to "100 MHz, which is fast enough to support a parallel interface clock of 90 Mhz".

Jeff

Thanks Jeff I'll look into that.  I did notice something strange related to the overflow problem and I can't quite explain it.  I was using the LCD output for my video loopback application and then changed to DVI output.  For some reason, once I changed to DVI the overflows were almost completely eliminated.  I maybe get 1 or 2 (sometimes none) in about 10-15 minutes as opposed to several per minute when using the LCD output.  I don't see any way that the output should affect the input driver so this was puzzling.

Jason,

Looking at the driver files you attached I noticed a reference to V4L2_IF_TYPE_RAW which is not defined in my version of the 2.6.32 kernel.  Did you have to modify omap34xxcam.c and add the V4L2_IF_TYPE_RAW type yourself or is that available as a patch somewhere on the web?  I only have type V4L2_IF_TYPE_BT656.

Thanks,

Jeff

Jeff,

Yes we had to add that type in - see the attached patch file.

- Jason

Jason,

Thanks for all your help.  I really appreciate it.  But, I still cannot get a stable image.  I am wondering if there are patches I need to make to the ISP/CCDC drivers to improve the RAW input.

Jeff

Jeff,

The previous two attachments contain everything I modified to get the camera working.  Are you confident in the imager setup and HW?  I am using a custom OV14810 imager board that we made and I have it wired over to the EVM J31 connector. 

- Jason

Jason,

Did you ever solve the issue of the

omap3isp omap3isp: omap34xx_isp_isr: sbl overflow

messages being printed out?

Jeff

Jeff,

I have gotten the overflow error to go away for the way I currently have things set up.  Reducing the pixel clock definitely helps.  But after I reached the limit of how far I could bring that down, I was still seeing overflows.  I've modified the driver to give me access to the data after the Previewer stage (bypassing the resizer).  I need to be flexible with the use of the resizer so I'm accessing it from within my user application.  I was getting lots of overflows when trying to do this.  To get rid of them, I had to increase the value of the RSZ_EXP register (see page 1282 of the TRM).  But if you are using the user space resizer driver, beware that the ioctl that is set up for this does not actually work.  There is a default value that always gets set in the driver - I had to go and stop that write from happening.

- Jason

Jason,

What criteria made you decide to go down that path of bypassing the resizer?  Is that something you found that was necessary in order to obtain high frame rates at higher resolutions?

Just wondering if I might be faced with a similar problem and need to pursue this approach.

Thanks,

Jeff

I have the need to possibly do multiple passes of the resizer, plus I'm just more comfortable using it this way since I've worked with the DM6437 a lot.  What I really need is to also bypass the previewer and access it in user space as well but I haven't been able to do this yet.  I need to run the full resolution image through the previewer (4416 line width) and the limitation is 4096 pixels so it would have to be multi-passed.  Have you done anything with full resolution capture with the OV14810?

- Jason

Jason,

Have you tried streaming video from the OV14810 to the display using one of the video overlay layers?  Specifically, I am trying to stream the 1104x828 video from the OV14810 to the display using the video layer and it always gets clipped at 720 lines.  The TRM states the DISPC_VIDn_SIZE can be max 2048x2048, so I am thinking there is an issue in the Linux Kernel somewhere.  Have you run across this?

Thanks,

Jeff

Jeff,

No I have never used the video overlay layers on the DM3730.

- Jason

Jason,

I read in this post that you built an OV14810 board.  I'm working on one myself now and I have the datasheet but am finding it lacking WRT details for schematic design.  Is there more information out there that I don't have that indicates, for instance what voltages the PVDD and EVDD pins should be tied to?

Thanks, Gail