C ASE STUDY: OV2715

CMOS S ENSOR
I NTEGRATION TO DM8127
IPNC
This document covers information on sensor driver development and integration
of Omnivision OV2715 CMOS image sensor to DM8127. The discussed interface
is proven and tested on the DM8127 based IPNC reference platform.

Akshay Panday, Ravikiran H, Radhesh Bhat

10/28/2012
2012 PathPartner Technology Consulting Pvt Ltd.,
www.pathpartnertech.com

10/28/2012

CASE STUDY: OV2715 CMOS SENSOR

INTEGRATION TO DM8127 IPNC
Introduction
The DM8127 IP Security camera reference design is available from Texas Instruments Inc
and features a 10MP CMOS image sensor interfaced to a high performance ARM Cortex A8
SoC. The DM8127 IPNC reference design is available with a single sensor option. There are
sensor boards available from third party suppliers which are electrically and physically
compatible with the DM8127 but do not have the required software compatibility. In this
document, we will cover the steps undertaken to interface one such sensor to the hardware
along with some insight into sensor driver development.
.

Hardware Descriptions
The TMDSIPCAM8127J3 is an IPNC reference design jointly developed by TI (www.ti.com)
and Appro Photoelectron (http://www.appropho.com) to demonstrate the capabilities of the
DM8127 platform in the surveillance market segment. The camera features a C-mount lens
and can encode video in several different format combinations. It has security features
including face detect, tamper detect, etc.

Figure 1 : DM8127 IPNC

The DM8127 is a high performance SoC featuring an ARM Cortex-A8 main processor and
hardware accelerators for video and imaging codecs. It features a dedicated hardware ISP
which can interface with a variety of image sensors and an image pipeline that can be tuned
to obtain the best quality image from each sensor.
The LI-CAM-OV2715 is a sensor board compatible with the DM3xx and DM8127 series
cameras. The OV2715 sensor mounted on it has an IR cut filter. The board has a proprietary
36pin connector for power, data and control signals.

www.pathpartnertech.com

10/28/2012

Figure 2 : OV2715 Sensor mounted on Sensor Board

The OV2715 is a 1/2.7, HD, CMOS sensor manufactured by OmniVision Technologies. It is a
10bit, parallel interface, RAW format device which has onboard AE, AWB and DPC
algorithms. Full HD (1920x1080) output is obtained at 30fps, while HD (1280x720) can be at
60fps. The sensor is controlled through OVs SCCB protocol which is compatible with I2C.
Following diagram shows the block diagram of OV2715.

Figure 3 : OV2715 Block Diagram

Integration Task List

The software used for this exercise was the IPNC RDK v3.0, which is a development kit for
the IPNC design. Of particular interest to us for this study are the ISS (Imaging SubSystem) Driver set and the McFW (Multi Channel Framework) which are part of RDK. The
ISS Driver has built in support for the Aptinas MT9J003 sensor with which the IPNC is
shipped. For our purposes, we must create a block set of settings for the new sensor keeping
in mind the data structures and APIs that the framework utilizes for this purpose.

www.pathpartnertech.com

10/28/2012

There are three major components here which must be programmed in such a way that the
resultant settings are compatible with each other and which result in a proper image at the
output.
a) Sensor which has to be set up according to manufacturer recommendations.
b) Programming the ISIF (Image Sensor Interface) and the IPIPE to expect the image
data in the exact format that the sensor is transmitting. Since the ISIF incorporates
a lot of flexibility to be compatible with a huge variety of sensors, programming it is
the most complex part of this task.
c) The third major aspect of sensor bring-up is to configure the application framework
for the new sensor. There may be additions in the framework structures to
accommodate the new sensors settings.
A further large task in tuning the IPIPE blocks to get a proper final image of good quality,
but that is beyond the scope of this document.

Sensor
The OV2715 uses an I2C compatible protocol for reading and writing to its registers and so
the existing driver interface can be used without modification. At the outset, it is necessary
to create the data structure necessary for the sensor object and allocate required memory for
it. Once this task is completed we can try basic read / writes to any of the sensor registers
using the correct slave ID to verify that the I2C read-write operations are working. Once this
is done, we can proceed to setting up the sensor. The manufacturer supplies a register
setting file for the common operating configuration of the sensor.

Sensor Driver details

The driver for OV2715 is developed for configuring the sensor registers and integrated to the
current ISS driver package available in the IPNC tool package.
Iss_Ov2715Create() This API is called once during the system initialization and used to
create the driver instance after verifying correct device ID (say ISS_SENSOR_OV2715_DRV)
Iss_Ov2715Init() This API is called to initialize the sensor registers with default values
provided from the manufacturer. The communication to sensor is through I2C with
appropriate read and write APIs.
Simialrly there needs to be corresponding implementation of deinit and delete API like
Iss_Ov2715DeInit() and Iss_Ov2715Delete().
The SYSTEM CONTROL00 register is set up first to so as to put the sensor in the correct
operation mode. Next, the timing control registers (0x3800 - 0x3818) are written to. The

www.pathpartnertech.com

10/28/2012
values used here are the manufacturer specified values. Since we are running the sensor at
the default 1080p@30fps, these values are unchanged.
The registers controlling the AEC/AGC, AWB and DPC modules are set to default values in
the init process. However, these modules are ultimately disabled since we will be using the
DM8127 IPIPE to perform these operations.

Image Sensor Interface (ISIF) & IPIPE

The ISS block mainly comprised of the ISP Block consisting of Image Sensor Interface (ISIF),
Image Pipe (IPIPE), Image Pipe Interface (IPIPEIF), and Hardware 3A Statistic Generator
(H3A). The ISS also contains additional HW block called SIMCOP for general image
processing purpose and details of which is beyond the scope of this document.
Figure 4 shows ISS ISP interface details in DM8127.

Figure 4 : ISS ISP Block Diagram

Image sensor interface (ISIF)- provides an interface to image sensors and digital video
sources.
Image pipe (IPIPE) is a parameterized hardwired image processing block whose image
processing functions can be customized for each sensor type to realize good still image
quality as well supporting video frame rates for digital still camera preview displays and
video recording modes.
Image IPIPE interface (IPIPEIF) is an extension to the input interface to the ISIF and
IPIPE modules. It can receive data from the sensor input, ISIF, and SDRAM. It performs

www.pathpartnertech.com

10/28/2012
some additional preprocessing operations on the data, and sends the resultant data to the
ISIF and IPIPE.
Hardware 3A (H3A) - is designed to support the control loops for auto focus (AF), auto
white balance (AWB) and auto exposure (AE) by collecting metrics on the RAW image data
from the image sensor interface (ISIF).

Programming Details
The IPIPEIF consists of two major interface blocks. It can receive data from both the sensor
parallel raw data via the device parallel port, and from the read buffer interface via
SDRAM/DDRAM. The input sources and data type (RAW or YUV) are configured in the
IPIPEIF_CFG1.INPSRC1 register field. We are selecting as VPORT_RAW in our usecase.
At the outset, the ISIF registers which establish the dimensions, signal direction and the
pixel clock of the sensor data are set:
ISIF_MODESET [1:4]
ISIF_MODESET:HDVDD
ISIF_HDW
ISIF_VDW
ISIF_PPLN
ISIF_LPFR
The image format and pixel format registers are set next:
ISIF_MODESET:CCDCMD
ISIF_MODESET:INPMOD
ISIF_CGAMMAWD:CFAP
ISIF_CCOLP
These establish that the image is Bayer RAW with BGGR pattern and Progressive. It is
necessary to ensure the data polarity setting of the ISIF matches that of the sensor. The ISIF
can support sensors with 16 bit data width. For sensors which do not utilize the full data
width of the ISIF we must verify the physical connection of the sensor data MSB to the ISIF
data pins and set the MSB position data register accordingly. This is set by writing into the
ISIF_CGAMMAWD:GWDI field. In this case we set the ISIF to expect 12 bit data as our
assumption is that the sensor board is set up for 12 bit data width. Setting this parameter to
10 bit results in saturation artifacts and hence the assumption that the sensor board is
transmitting [9:0] data to [11:2] lines of ISIF. At this stage, the IPIPE registers must be
programmed to pick out the valid data area from the image data generated by the ISIF
(IPIPE_SRC_MODE,
IPIPE_SRC_HPS,
IPIPE_SRC_VPS,
IPIPE_SRC_VSZ,
IPIPE_SRC_HSZ). The IPIPE will then operate on this window of data only. The
ISIF_MODESET:CCDW register sets the number of right shifts necessary when saving the
data to SDRAM so that the LSB is at 0th position. It is set in tandem with the
ISIF_CGAMMAWD:GWDI. It is also necessary to set up the Resizer registers to process the
valid data area. Since the Resizer is already set up process 1080p data, the modification to
the Resizer register set is minimal.

www.pathpartnertech.com

10/28/2012

Application Framework
We need to add some sensor specific changes to the multichannel framework to ensure that
we truly have end-to-end support for the device. While initial setup and experimentation can
be accomplished by reusing code from existing sensors or by hard coding changes into the
driver to work with the new sensor, these parameters must be separated out into sensor
specific sets later.
At a high level, the sensor slave ID and the device instance ID need to be set. These are
hardware dependent and would already have been ascertained at the sensor bring up stage
itself. The IPNC software supports multiple channels of encode across a variety of
resolutions and formats. These are generated either via the resizer or by changing the sensor
configuration. Hence we must program the various sensor configurations (eg: 1080p@30,
720p@60) to enable the system to switch based on user input. TI supplies an Image Tuning
Tool - standalone software running on a host PC that is used for tuning various blocks of the
IPIPE and ISIF for good image quality. The ITT also needs to access the sensor register
space for certain parameter settings. Hence the sensor base address should be correctly set
in the framework.
At this point, we have a viable image from the system that is free of artifacts and other
irregularities. Figure 5 shows the snapshot of the captured image after integration.

Figure 5 : Snapshot from OV2715 after integration to IPNC

Note that the captured image is with defualt IPIPE parameters which is not tuned for the
OV2715 sensor.
The next task is to tune the Image Pipeline for best image quality. This is a subjective
process and is done mainly through the Image Tuning Tool supplied by the silicon vendor.
Different lighting and scene conditions are evaluated and the IPIPE is configured so as to
generate a pleasing image under all conditions.
The ITT also needs to access the sensor register space for certain parameter settings. Hence
the sensor base address should be correctly set in the framework.

www.pathpartnertech.com

10/28/2012

References
[1] DM814x ISS Datasheet
[2] OV2175 CMOS Sensor datasheet
[3] http://www.ti.com/lit/ug/sprugz8b/sprugz8b.pdf
[4] http://www.ti.com/lit/ug/sprufg8c/sprufg8c.pdf
[5] http://www.ovt.com

Reach us at:
PathPartner Technology Consulting Pvt Ltd,
#6, Zeeshan Arch, Jeevan Bhima Nagar Main Road,
H.A.L. III Stage, Bangalore - 560 075 (INDIA)
T: +91-80-40101900 F: +91-80-40101950
E-mail: sales@pathpartnertech.com
Web:

www.pathpartnertech.com

www.pathpartnertech.com