MCF5329: LCDC Maximum Frequency Confusion, 20, 27 or 40MHz?

[TomE]

What's the maximum pixel clock rate on the MCF5329 LCD Controller?

If you're doing a new design and are trying to work this out there's only a 30% chance you'll find the "right" answer.

According to:

    MCF5329RM.pdf

    MCF5329 Reference Manual

    22.3.7 LCDC Panel Configuration Register (LCD_PCR)

    Note: Set PCD so that the LCD_LSCLK frequency is less than one-third (TFT mode)

             or one-fourth (CSTN mode) of the system bus clock (fsys/3) frequency.

    "LESS THAN 1/3" is 1/4, so the maximum frequency is 80MHz/4 or 20MHz.

According to:

    AN3606.pdf

    Understanding LCD Memory and Bus Bandwidth Requirements

    Table 2. Bus Bandwidth Usage for Color LCD Panels

    Currently, the ColdFire processors that include the graphical LCDC

   support a maximum pixel clock frequency of 26.66 MHz;

According to:

    MCF5329DS.pdf

    5.10 LCD Controller Timing Specifications

    T1 LCD_LSCLK Period   min = 25ns,  max = 2000 ns

    Which is 40MHz.

I suspect that only the App Note is correct. The Reference Manual probably meant to state "less than or equal to 1/3" but doesn't. The control registers allow for a 40MHz clock (as per the Data Sheet), but it isn't a supported frequency.

It isn't documented anywhere that at 26.66MHz the pixel clock has a 30% duty cycle. That might cause problems with some video hardware or panels.

Tom (A Random Poster)

[J2MEJediMaster]

Submit a service request on this, for a documentation error. I know you have had mixed results with that before, but give it a try.

---Tom

[TomE]

I received the following back via our local rep:

The manual should say that for TFT mode the LSCLK frequency should be 1/3 or less than the system bus clock. They are missing the important = in the =< statement. The datasheet is actually ok, since technically you can have an LSCLK that is system clock/2 (which gives you a max of 40MHz or 25ns period). This would pretty much only be allowable for monochrome mode where you wouldn’t need a 40MHz clock anyway, but as an absolute maximum rating the datasheet is right.

I’ll talk to the documentation team about updating the description of  PCD field.

I don't think I need to submit a Service Request given the information has already been sent to the documentation team. Thanks for the reminder though.

Tom (A Random Poster)

[maxhexis]

Hi Tom,

just few additional words about the 33% duty cycle problem.

If you use an LVDS seriaizer, like the 75LVDS84, the internal clock multiplier has no problem to regenerate a clean 7x serial clock for the high speed interface.

Anyway, if you need a 50% duty cycle clock for your panel, a simple circuit using a DLL or PLL will suffice, for example the CDCF5801. Of course unit cost is slightly increased.

Last, just a curiosity: anybody tried to set che LCD clock divider to /2? Which is the effect?

Best regards,

[TomE]

> Last, just a curiosity: anybody tried to set che LCD clock divider to /2? Which is the effect?

 I can do that easily at the moment as I'm working on LCDC programming.

The result is weird. I'm pretty sure I'm only changing the LCD Divider clock, while leaving all the other programming as-is.

With the divider set to /2 the pixel clock is running at 40MHz. That works as expected.

The picture on the screen is stable, but is double the width I'd expect. I'm only getting half of the pixels displayed, meaning each pixel is being displayed twice.

The Vertical Sync pulses are being generated at the following rate for the different divider ratios:

Divide by 5 (16.00MHz): 34.92Hz

Divide by 4 (20.00MHz): 43.65Hz

Divide by 3 (26.67MHz): 58.19Hz

Divide by 2 (40.00MHz): 50.28Hz

If the divider chain was working properly the Vertical Sync pulses should be double 43.65Hz = 87.30Hz. Instead the chip is generating 50.28, which is 0.5759 of that. That's not a ratio of simple numbers. It is close to the square root of 1/3, which doesn't make any sense.

The Horizontal Sync pulses, which were running at 26.18kHz at 20MHz are alternating (in bursts) between 27.29kHz and 52.36kHz.

My guess is that when it isn't trying to access memory (in the vertical blanking period) the dividers are working as expected and generating the high horizontal rate, but that the /2 divider rate is way too high to be able to keep the pixel FIFO full and it is "slipping clocks" in the divider chain, slowing down to about half.

Checking App Note AN3606 gives a memory bandwidth of 84 MB/s at 16 bpp and 26.67MHz, so at 40MHz it would be trying to read memory at 84*3/2 or 126MB/s. That App Note gives the memory bandwidth at 128MB/s, but my measurements show it is only capable of 10/11 of that at most. So I'm over 100%. It would probably do something different at 8 bpp or 4 bpp, or it may be the DMA controller can't handle the /2 clock divider.

This is operating outside of the published manufacturer specifications anyway.

Tom