ISS Image Sensor Drivers MT9P003/MT9J031

Chris,

I'm not familiar with the ISS 2.x package but I am familiar with the DVSDK 4.x for the DM36x EVM with the LI-5M02 Camera Board which utilizes the Aptina MT9P031 CMOS sensor. DVSDK 4.x contains a driver for the MT9P031 that works well and is reasonably documented with sample applications showing how to access the DM36x AEW and AF Engines.

Regards,

-Chuck

Hi Chris,

The driver for Aptina sensor MT9P031 has been validated in the ISS 02.00.00.00 driver package. The IPNC actually ships with MT9J003 sensor (Aptina) which is also 12-bits and we process all the 12-bits till color conversion.

As I understand you are using a 12-bit sensor but have connected only the upper 10-bits to the input bus. In that case you may want to correct the MSB bit position value in the driver code. But it still does not explain why you are seeing only 4bits of MSBs! Did you try the RAW dump from ISIF and verify the RAW dump?

Rajat,

I'd love to be able to dump RAW from the ISIF. How do I accomplish that?

I tried to use the MT9P031 driver in ISS 2.0.0.0, but noticed something very strange: my MT9P031 sensor has 8 bit i2c registers but the ISS driver has 16 bit addresses. I'm not sure how to square that difference.

Thanks,

Christopher

We will support RAW stream output in ver 2.8.0 of ipnc rdk.

But even in the version that you have you can implement continous or snapshot based RAW capture from ISIF. Can you please review the IssCaptureRawFrame() method in issdrv_captureApi.c file. This should give you a way to implement the raw capture.

Regards

Rajat Sagar

Rajat,

Thanks. I found that function and the supporting code, but I'm still having strange troubles. When I attempt to capture a frame, after the second full frame has been received (the interrupt triggers the capture stop), my buffer has only two lines of bayer data (it's not correct, but that's a problem for later). Any idea what's up?

Also the CADU/CADL registers seem to be automatically cleared. Is this supposed to be happening? What part of the system clears this register?I don't see it in the spec anywhere.

Thanks,

Christopher

Did you comment the "raw_data_done = 1;" condition in issdrv_captureApi.c file?

The reason you are seeing CADU/CADL being cleared is that at the next VD interrupt the raw_data_done condition is stopping the ISIF raw capture. We are planning the ver.2.8.0 release next week - it will have support for continous raw capture.

Regards

Rajat

Rajat,

I'm using ISS 2.0.0.0 (from Appro GA 2.0). Removing "raw_data_done = 1;" wouldn't do much good because raw_data_done is set only once and never read. It appears to be old code that was not cleaned up. Perhaps you're looking at another file/version.

Taking another look at the code, CADU/CADL are being cleared because the call to issTriggerRawCapture() sets CADU/CADL to 0 when called with ISIF_STOP_WRITE. That makes sense.

Perhaps I'm failing to understand how this is supposed to work, so let me go through the flow:

1. The VD interrupt is triggered once per frame (it's effectively the vertical sync notice). I'm capturing 1080p, so VD will be triggered once for every 1080 rows.
2. When the VD interrupt fires, isp_isif_linenum_handle() is called.
3. To start a capture, issTriggerRawCapture() sets CADU/CADL to point to my buffer, ISIF_START_WRITE is set, and gRawCaptureTriggered is set to '1'.
4. At this point, rows are being written to my buffer, starting wherever we happen to be in the frame.
5. The first VD interrupt is ignored by the capture code (this just signals the start of the next full frame).
6. The second VD interrupt (we now have a full frame) causes the memory capture to stop (ISIF_STOP_WRITE) and signals the caller that the buffer now contains a full frame.

It does appear that bufSwitchFull() sets Raw_Data_Ready too quickly, but that shouldn't matter for two reasons:

1. It takes my debug code so long to print out the frame buffer (far more than 1/30th of a second) that the buffer would be full by the time I got to it anyway.
2. Even if the capture stop were being triggered on the first VD interrupt, I would see some random amount of frame -- not always two rows.

So, am I correct in my assumption that the VD interrupt fires once per frame and not after every row? If VD fired after every row, it would explain why I get two rows instead of a full frame.

Also, are CADU/CADL treated a "start of frame" buffer pointer or, if capture was never stopped, would all of memory be filled with frames? It's really not clear from the specification how this is feature operates.

Thanks,

Christopher