AM3517 EVM display glitches.

Hi Krunal,

Let me clarify and share some important data regarding AM3517EVM before commenting anything further,

On AM3517 EVM, we have known hardware (EVM/board connectivity) issue with VPFE capture, where data pins Y0-Y9 directly interfaced to CCDC DAT0-DAT9 which results in loss of upper 2 bits.

In case of OMAP3, we have bridge lane shifter which allows you to convert this 10 bit data into 8bit by ignoring lower 2 bits, which is obviously not possible in AM3517.

So the work-around we applied in driver & application is, configure CCDC into raw mode interface and enable A-Law to convert 10bit raw to 8 bit data. In application, again we are applying reverse A-Law and trying to get actual color data.

Coming to your question,

Flicker on Display - I believe this is definitely capture module issue, and could be side effect of A-law and reverse A-Law mechanism as explained above. Can you please share more details on your findings, when you say "data going to display is correct"?

alaw mapping table in application- On customer board, you shouldn't be using it. This is required only for AM3517EVM.

Thanks,

Vaibhav

Hello Vaibhav,

Thanks for the reply. Today I had done some experiments with EVM sample application (saMmapLoopback.c) and here are my findings:

• Executed TI saMmapLoopback application without any modification, glitches are observed.

• I stored captured data (after alaw mapping table) into file. I did not see any glitches in the captured data. Right now I don't have modified code here with me, following is the pseudo code for what I did:

           while(1) {

                DQUE display buffer

                DQUE capture buffer

                disp_buf[i] = alawmapping[cap_buf[i]];

                fwrite(disp_buf, 1, height*width*2, fp)

                QUE capture buffer

                QUE display buffer

             }

• Instead of sending captured buffer to display sub system, I have disabled ALAW mapping and provided different color frame for every alternate frame i.e 1st green, 2nd red, 3rd black ....glitches are observed in this case as well. following is the pseudo code:

           while(1) {

                DQUE display buffer

                DQUE capture buffer

                color_bar(disp_buf)

                QUE capture buffer

                QUE display buffer

             }

• Disabled capture QUE/DQUE code and provided and provided different color frame for every alternate frame i.e 1st green, 2nd red, 3rd black ....The glitches are gone in this case as well. following is the pseudo code:

           while(1) {

                DQUE display buffer

# if 0

                DQUE capture buffer

#endif

                color_bar(disp_buf)

#if 0

                QUE capture buffer

#endif

                QUE display buffer

             }

• Executed saV4l2Display.c application without any modification and glitches does not appear with this application.

Summary: From above experiments what I can say is whenever capture and display are used simultaneously, that is causing glitches on the display.

Additional Query: I have an AM3505 + DM6467 based custom hardware (two processors on single board), where DM6467 display lines (BT656) are directly connected to AM3505 capture (D9:D2).There are three cases with my configuration:

Case 1: Not getting capture interrupts:

• ALAW Configuration Register, 0x5C06004C bit 3, to 0 (disabled)
• CCD Configuration Register, 0x5C060054 bit 5, from 0 (8 bit)
• SYN_MODE Register, 0x5C060008 bit 11, to 1 (Pack 8 mode)

Case 2: Getting capture interrupts:

• ALAW Configuration Register, 0x5C06004C bit 3, to 1 (enabled)
• CCD Configuration Register, 0x5C060054 bit 5, from 1 (10 bit)
• SYN_MODE Register, 0x5C060008 bit 11, to 1 (Pack 8 mode)

Case 3: Getting capture interrupts but no data (buffer set to 0x80):

• ALAW Configuration Register, 0x5C06004C bit 3, to 0 (disable)
• CCD Configuration Register, 0x5C060054 bit 5, from 1 (10 bit)
• SYN_MODE Register, 0x5C060008 bit 11, to 1 (Pack 8 mode)

Ideally I should get my driver working with case 1 configurations, but it is working with case 2. I don't mind configuring it as 10 bit interface but I am not able to figure out what is the dependency on ALAW configuration. Our design should not require ALAW operation.

Let me share here: I observed glitches issue on this custom board as well (with case 2 configurations - as my driver is running with this configurations only). Looking at the application code I suspected the glitches are caused by that ALAW mapping table. To verify this I move to AM3517 EVM and executed TI saMmapLoopback application on EVM board. I was surprised looking at same glitches on EVM too.

Please let me know your thoughts on glitches on EVM and above issue. Display glitches are not good for us, your any help will be appreciated!!

--

Regards,

Krunal

Hello Vaibhav,

Today I tried to slow down the FPS. I inserted 1 sec sleep in the capture/display loop to see what happns. I was surprised with that also, I was able to see glitches. I could not figure out what is causing this glitches? Did you get chance to look at above issue? Do you think this can be a DMA performance or DDR refresh rate issue?

--

Regards,

Krunal

Hi Krunal,

Reducing FPS won't help here, I still think the problem is with alaw operation on YUV data. We are considering YUV information as raw data (10 bit) and then converting it to 8bit raw data and again applying reverse alaw to get original color information.

Can you try capturing still image and see whether you see glitches all the time? if you are capturing contiguous video then it would be hard to say why glitches are coming, may be it depends on color loss for that frame (and certain color components).

Thanks,

Vaibhav

Hello Vaibhav,

I tried disabling ALAW in driver and application. I am using 10 bit mode but I am getting distorted colors in the captured image.

                                        Captured Data

                                        Original Data

--

Regards,

Krunal