AM1808 with WVGA Active TFT Display: Issues with Pixel clock

Hi Adnan,

From a HW point of view, I would suggest you to read 5.24.2 of the datasheet to understanding the switching characteristics of LCDC. The max PCLK supported by LCDC is 30MHz when core voltage is 1.0V and 37.5MHz when core voltage is 1.1-1.3v.

Please clarify your findings.

1. Regarding your comment,

Adnan Yunus said:

Upon doing some probing, it appears that the Pixel clock stops coming in. 

Do you mean the LCD_PCLK does not toggle anymore?

2.

Adnan Yunus said:

The typical pixel clock for this display is suppose to be 33MHz. If I reduce it down to 15Mhz, I can see the Matrix demo as intended (disregarding the flicker). However, any thing over that frequency makes the display behavior unpredictable. 

Are you reducing the PCLK? Please elaborate on what exactly you have tried/observed. How are you reducing the pixel clock?

Do you mean the LCD_PCLK does not toggle anymore?

That is correct. Perhaps an buffer underflow interrupt is causing the raster to turn off. I'm still investigating why. 

Are you reducing the PCLK? Please elaborate on what exactly you have tried/observed. How are you reducing the pixel clock?

Yes. When the pixel clock is anywhere below 20Mhz, the display seems to work. From 20Mhz to 25Mhz, the pixel clock still continues to switch but framebuffer is not being displayed properly. And by that, I mean that a portion of frame which is suppose to be on first quarter of display is displayed at the end. 

Also, it will solve the flickering issue even if I can drive the display at 30MHz. So far, it becomes unstable even after 20MHz.

As for how I'm reducing the Pixel clock, according to datasheet, bits 15-8 in LCD_CTRL sets the divider value for LCDC incoming clock. Since my incoming clock is set at 150MHz, I'm using the value 5 on these bits to set the frequency to 30MHz. To reduce it further, I'm using higher values ranging from 6 to 10. 

Got you Adnan, Thanks.

Could you please let us know what other activity there are in the system? Also, I am not sure what you meant in the following statement.

Adnan Yunus said:

Also, it will solve the flickering issue even if I can drive the display at 30MHz. So far, it becomes unstable even after 20MHz.

What speed is the memory running at in this application. As a sanity check, are you able to increase the speed on that and see if the flickering/corruption goes away?

Are you able to print out all the LCDC registers when the clock disappears? I would like to examine the setting as well as the error status.

regards,

Paul

Paul.Yin said:

Got you Adnan, Thanks.

Could you please let us know what other activity there are in the system? Also, I am not sure what you meant in the following statement.

Also, it will solve the flickering issue even if I can drive the display at 30MHz. So far, it becomes unstable even after 20MHz.

What speed is the memory running at in this application. As a sanity check, are you able to increase the speed on that and see if the flickering/corruption goes away?

Are you able to print out all the LCDC registers when the clock disappears? I would like to examine the setting as well as the error status.

regards,

Paul

[/quote]

By that I mean that If I can drive the pixel clock at 30MHz, which you  mentioned as the upper limit in previous post, the flickering will go away. 

As for the memory, I have a DDR2 running at 150MHz. 

I just verified that we're using 1.2v so we should be able to go as up as 37MHz according to the datasheet. 

Adnan,

Sorry. Just to be 100% sure that I understand what you are saying.. Your video works below 20 MHz and @ 30MHz. You see flickering/corruption only between 20 and 30MHz. correct? -- From what you are saying above, 30MHz is OK, but your original message said anything above 15MHz is bad.

Please also comment on my original questions:

1. Could you please let us know what other activity there are in the system?

2. Could you please print out all the LCDC registers when the clock disappears? I would like to examine the setting as well as the error status.

Paul.Yin said:

Sorry. Just to be 100% sure that I understand what you are saying.. Your video works below 20 MHz and @ 30MHz. You see flickering/corruption only between 20 and 30MHz. correct? -- From what you are saying above, 30MHz is OK, but your original message said anything above 15MHz is bad.

Hey Paul,

Not quite. 

The Video runs below 20MHz. 

Video still appears from 20MHz to 25MHz but with incorrect image.

Video stops anything above 25MHz. 

30MHz would be quite satisfactory, IF I could get it to work. Its not working right now. 

Please also comment on my original questions:

1. Could you please let us know what other activity there are in the system?

2. Could you please print out all the LCDC registers when the clock disappears? I would like to examine the setting as well as the error status.

In answer to your questions: 

1. The base system is linux with Matrix_guiE demo running on top. It is based upon the TI 5.02 Linux SDK for AM1808. The linux kernel is modified to support the custom hardware including LCD display and RAM.

2. I'm working on it. Do you have a suggestion how to print those registers out with Linux running? I'm trying to setup the gdbserver, however the software setup guide and wiki is obsolete and refers to things that aren't quite correct. Also my installation of CCS doesn't seem to have debug option for "C++ remote application". 

If you don't have any ideas then I'll just reinstall it and hope for it to work. Will let you know once I have an update. 

Thanks. 

Got you Adnan,

I am going to move this to the Linux forum, but I will keep monitoring this thread.

Hopefully the Linux expert can comment on the performance benchmarking as well as debug support.

regards,

Paul

Hey Paul,

After looking at TI page for AM1808, I noticed that there is a new version for the SDK available. I'm going to upgrade to that and see if it fixes problem related to CCS and let me pull the register values. 

Thanks for your prompt replies. 

Vaibhav Hiremath said:

I may not be able to help you from AM1808 point of view, I never worked on it. But to dump the registers from Linux prompt you can very much use devmem tool. Just google for devmem2 tool, it is free and pretty easy to use.

Thanks,

Vaibhav

Thanks for the tip Vaibhav. It helped a lot. I think I'm much closer to resolving this issue now. 

It took a bit longer for me to come back with an update since I was occupied with additional work related to touchscreen functionality but I have more information regarding the issue. 

There is a FIFO Underflow which turns off the raster and attempt to turn it back on. 

Additional details on system: The display is a WVGA 800x480x16bpp which should put the framebuffer size at about 768Kb which isn't overly huge. The memory is a DDR2 running at 150MHz.

Unless I'm missing something, there isn't any reason for a buffer underflow. Does any of the TI guys or Display driver veterans here have any theories/ideas as to what could be causing it? 

Hi Mukul,

Thanks for the reply.

It seems that for all practical purposes, the Pixel Clock value of AM1808 LCDC controller is limited to a particular threshold. After setting the LCDC priority to 0 and decreasing the Bus Burst Priority to 10, the pixel clock goes up to 30MHz when the processor is running at 456MHz.

I haven't actually tested it but based upon the analysis that you linked, my guess is that this threshold will be lower if the processor is running at @300MHz.

While this is still lower than ideal, it seems to mostly resolve the flicker issue that I was having so I would mark this as answered. 

Thanks