i.MX RT using external clock source to generate video clock

[SammyP]

I have an application where I am capturing video data using the CSI, buffering it and displaying using the eLCDIF.

I am trying to find the best way to synchronize the eLCDIF video clock with an external input clock from my video source (preferrably HSYNC).

At first glance, it seemed like I could use the CLK1 external reference clock input. It has a range of 1Hz to 100MHz. However, the Video PLL (PLL5) only allows a 24MHz input clock so unfortunately there is no way for me to lock the Video PLL to an external source (unless it's 24MHz).

Will the video PLL not work at all at different frequencies? Is there any way to achieve what I want without using an external PLL?

[jeremyzhou]

Hi，
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
To be honest, I'm not very clear about your purpose, whether you want to use the CSI_HSYNC as the input clock to connect the CLK1 for the Video PLL, if yes, the input clock must be 24 MHz, and hope this is clear.
Have a great day,
TIC

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[SammyP]

My application seems pretty standard. I'm using double buffering to capture a frame in one buffer, while the other buffer is being used for the eLCDIF. After every VSYNC, the buffers are swapped. My video source (i.e. camera) needs to be synced to the video output (i.e. display).

My target is basically to synchronize the eLCDIF to the CSI. If they are not exactly generating/displaying frames at the same rate and for example, the CSI is slightly faster (e.g. 60fps vs 59.95fps), then eventually there will be enough drift so that the double buffering will be disturbed (buffer 1 will be full before buffer 2 has been completely flushed). Dropped frames are not acceptable for me and I also don't want incomplete frames. Again, this all seems pretty reasonable.

As I don't really see a way to generate an LCD pixel clock that is locked to the CSI VSYNC using the internal PLL's, I had another look at the options available for the eLCDIF peripheral.

In DOTCLK_MODE, the peripheral normally continuously fetches and displays new frames without any breaks. However, there is an option to set BYPASS_COUNT to 0 in the LCDIF_CTRL register and manually control the RUN bit in LCDIF_CTRL to start the transfers. Would it be reasonable to use an external interrupt connected to the VSYNC_IN and toggle the RUN bit in an interrupt handler? I'm a bit worried about jitter, but perhaps it could be acceptable if the interrupt is handled fast enough.

[jeremyzhou]

Hi,
Thanks for your reply.
In my opinion, it's essential to assuring the LCD's refresh rate exceeds the camera's, meanwhile, benefit enough RAM buffer, it can definitely assure the LCD display the video in time.
Lastly, you can refer to the application note to learn the details.
Have a great day,
TIC

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------