sct flexible camera solution with 10635

yuaneast · ‎03-08-2018

I use same program struct like sct flexible camera solution AN11365, using lpc4350,the board m4 clock is 192mh(192/8=24MH),and change cmos chip to Ov10635, and transfer image via usb. the problem is the picture always with horizon line go from up to down (for high frequency) or from bottom to up(for low frequency). the ov10635 normal working xclk is 24MH, but only when I reduce the xclk to 12MH and below , the picture will ok.

it seems that the href blank time is not long enough to deal with interupt ,which reload dma configuration. hope somebody can help me.

thanks

lpcware‌# DMA sct camera solution

Hui_Ma · ‎08-02-2018

Dear Yuan

Thank you for the info.

I checked the LPC43xx AHB multilayer matrix configuration, which using a round robin arbitration scheme to select which AHB master occupied the bus slave.

Follow with you analysis, there exists AHB bus conflict. Where could be the root cause?

GPDMA and USB module compete to gain the external memory access right.

If so, it also could explain disable USB module interrupt make the GPDMA works normally(avoid AHB conflict between GPDMA vs. USB).

Have a great day,
Mike

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

yuaneast · ‎03-30-2018

hi,Mike,thank you.

then what is the solution ? or what we can do to improve the frequency a little bit?

Yuan

yuaneast · ‎07-24-2018

Hi,Mike.

I think I already find the real reason . at the beginning, we think the gpio speed is not fast enough. but when I colse the usb interrupt, the gpdma did not lose data anymore, so the real problem is the the usb transfer interrupt affect the gpdma transfer. the gpdma burst request is from SCT input5.

but even I moved the usb interrupt function to M0 ,or move SCT interrupt to M0, nothing happened .

so I think something conflict between gpdma and usb.

I need your help.

Thanks

Yuan

Hui_Ma · ‎08-01-2018

Hi Yuan,

First of all, sorry for the so later reply.

I just back to office from one week absence.

Thank you for sharing what your found.

With your description, the USB interrupt service will affect the gpdma transfer.

I checked the AN11365 source code, the GPDMA initialize code was called at SCT IRQ.

Could you try to enhance the GPDMA and SCT interrupt priority higher than USB interrupt?

Please let us know the result. Thanks.

Have a great day,
Mike

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

yuaneast · ‎08-01-2018

Dear Mike：

I think the main problem is the AHB bus conflict.

I select AHB M1 for source data and Select AHB M0 for Memory, I think

USB also use M0 or M1, so this cause conflict. and I tried to use AHB M1

for memory, the situation became worse.

I also tried to move interrupt to the M0 core side, there was no effect.

so I think that is not a conflict of the interrupt, it is a conflict of

AHB bus.

Thanks.

Yuan

2018-08-01 21:13 GMT+08:00 East Yuan <yuanyantai@gmail.com>:

Mike:
thanks for your reply.
I tried to set the USB interrupt priority lower or higher than SCT
interrupt, but the same effect.
Thanks,
Yuan
2018-08-01 15:39 GMT+08:00 Hui_Ma <admin@community.nxp.com>:

>> NXP Community

>> <https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg>

>> Re: sct flexible camera solution with 10635

>>

>> reply from Hui_Ma

>> <https://community.nxp.com/people/Hui_Ma?et=watches.email.thread> in *LPC

>> Microcontrollers* - View the full discussion

>> <https://community.nxp.com/message/1040869?commentID=1040869&et=watches.email.thread#comment-1040869>

>>

yuaneast · ‎08-01-2018

Mike:

thanks for your reply.

I tried to set the USB interrupt priority lower or higher than SCT

interrupt, but the same effect.

Thanks,

Yuan

2018-08-01 15:39 GMT+08:00 Hui_Ma <admin@community.nxp.com>:

NXP Community
<https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg>
Re: sct flexible camera solution with 10635
reply from Hui_Ma
<https://community.nxp.com/people/Hui_Ma?et=watches.email.thread> in *LPC
Microcontrollers* - View the full discussion
<https://community.nxp.com/message/1040869?commentID=1040869&et=watches.email.thread#comment-1040869>

yuaneast · ‎03-20-2018

thanks ，Mike.

there are no LCD, gpdma received data ,and transfer to usb, the image is from PC. the xclk target module is ov10635.

best regards

Yuan

Hui_Ma · ‎03-21-2018

Hi,

There seems when OV10635 works at 24MHz, the gpdma doesn't have bandwidth to transfer all data to USB.

When slow down the bandwidth requirement, the gpdma will transfer all data to USB.

What's the GPDMA working clock? 192MHz?

What's the GPDMA burst size? 256?

Thank you for the attention.

Have a great day,
Mike

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

yuaneast · ‎03-21-2018

Hi, Mike:

What's the GPDMA working clock?

yes, 192MHz..

What's the GPDMA burst size?

burst size ,peripherial side is 1,and memory side is 4.

thanks

2018-03-21 17:05 GMT+08:00 Hui_Ma <admin@community.nxp.com>:

NXP Community
<https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg>
Re: sct flexible camera solution with 10635
reply from Hui_Ma
<https://community.nxp.com/people/Hui_Ma?et=watches.email.thread> in LPC
- View the full discussion
<https://community.nxp.com/message/997664?commentID=997664&et=watches.email.thread#comment-997664>

Hui_Ma · ‎03-27-2018

Hi,

The root cause is because the GPIO module is not a fast peripheral.

If there using higher frequency to transfer data from GPIO register to memory, the GPIO register doesn't updated the correct data from OV10635. There will cause DMA read the incorrect data and transfer to LCD display buffer.

Then LCD will read the incorrect data and display abnormally.

Thank you for the attention.

Have a great day,
Mike

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

Hui_Ma · ‎03-15-2018

Hi,

Do your system has external memory, such as SDRAM?

If yes, please try to use external memory as camera data buffer.

If there still with the same problem?

Thank you for the attention.

Have a great day,
Mike

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

yuaneast · ‎03-18-2018

Thanks Mike,

I have sdram, I am using it as buffer ,but still same problem.

Hui_Ma · ‎03-19-2018

Hi,

There are two factors will affect the LCD display issue: one is camera ov10635 doesn't provide the correct data; the other is LCD data bandwidth affect the display.

From your description: only when I reduce the xclk to 12MH and below , the picture will ok.

What's the xclk clock target module: LCD controller or camera ov10635?

Best regards,

Mike