Call to arms | Teensy + SDRAM = true

So using dogbones board im driving a controllerless 800x480 display from buydisplay.com

I've made an adaptor pcb with a constant current driver for the backlight as well as a 40 pin ziff connector (had to hand solder, forgot to click the stencil option)

So running in dotclock mode (using hsync, vsync and enable) im running a 20mhz pixel clock with a screen refresh rate of 50hz. A front and backbuffer is in sdram, and these are both being driven out to the lcdif pins via the lcd engine.

This works fine so far (except im missing the first 4 rows of lines being displayed) ive tested using a 32 bit buffer (with 3 bytes per pixel) and rgb 565 16 bit buffer.

The lcd engine actually does alright getting the buffer out of sdram into its own buffer in a timely manner.

Without the lcd engine running, In sdram using a for loop to fill uint32_t 384000 element array was about 4 milliseconds. When running the lcd engine outputting to the display and filling this array - this only increased slightly to an extra half a millisecond (I expected worse - sdram read to lcd buffer must be quicker than sdram read to cpu)

However there's 1 problem I can't solve. The display uses ST7277 to drive the actual pixels.

Whether im in 16 bit mode or 24 bit mode, if I have full white in the buffer the display goes wierd. It has to be full white. The whole display can be the colour 255,255,254 and its fine

If I add 5 rows of 255,255,255, those rows will have black artefact lines randomly flashing through.

If I add 40 rows of white, the artifscts are worse, and every couple seconds the display will randomly flash with junk colours.

Yet as long as there's no full white pixels everything is fine. It's extremely strange.
 

Attachments

  • Screenshot_20250314_212920_Gallery.jpg
    Screenshot_20250314_212920_Gallery.jpg
    239.5 KB · Views: 166
theboot900 said:
However there's 1 problem I can't solve. The display uses ST7277 to drive the actual pixels.
Click to expand...

I'm also driving an 800x480 display with the ST7277. I had issues similar to what you described but was able to resolve it.

Here are the settings I ended up with:
C++: 
  static constexpr uint32_t kHeight = 480;
  static constexpr uint32_t kVerticalFrontPorch = 14;
  static constexpr uint32_t kVerticalSyncWidth = 2;
  static constexpr uint32_t kVerticalBackPorch = 14;
  static constexpr uint32_t kWidth = 800;
  static constexpr uint32_t kHorizontalFrontPorch = 6;
  static constexpr uint32_t kHorizontalSyncWidth = 3;
  static constexpr uint32_t kHorizontalBackPorch = 6;
  static constexpr uint32_t kPixelClockNumerator = 25;
  static constexpr uint32_t kPixelClockDenominator = 24;
  static constexpr uint32_t kVsyncPolarity = 0;
  static constexpr uint32_t kHsyncPolarity = 0;

And then I needed to set the dot clock polarity bit in the LCDIF_VDCTRL0 register:
C++: 
LCDIF_VDCTRL0 = LCDIF_VDCTRL0_ENABLE_PRESENT |
     LCDIF_VDCTRL0_VSYNC_PERIOD_UNIT |
     LCDIF_VDCTRL0_VSYNC_PULSE_WIDTH_UNIT |
     LCDIF_VDCTRL0_VSYNC_PULSE_WIDTH(config_.verticalSyncWidth) |
     config_.vsyncPolarity |
     config_.hsyncPolarity |
     LCDIF_VDCTRL0_DOTCLK_POL;

Hope this helps!
 
sndsgd said:
Hope this helps!
Click to expand...
It sure did!!!!

10 hours of trouble shooting this and you have just solved it.

i needed to set the DockCLK Polarity.

I also needed to reverse the polarity on the Vsync and HSync to get it to work

LCDIF_VDCTRL0 = LCDIF_VDCTRL0_ENABLE_PRESENT |
LCDIF_VDCTRL0_VSYNC_PERIOD_UNIT |
LCDIF_VDCTRL0_VSYNC_PULSE_WIDTH_UNIT |
LCDIF_VDCTRL0_VSYNC_PULSE_WIDTH(verticalSyncWidth) |
LCDIF_VDCTRL0_VSYNC_POL |
LCDIF_VDCTRL0_HSYNC_POL |
LCDIF_VDCTRL0_DOTCLK_POL;

I was starting to think the ST7277 was faulty. All the data signals where coming out correctly on the scope yet the screen was a mess as soon as i had full white pixels on it.

I seem to be missing the first row of pixels, but ill see if playing around with the porches will fix that
 
Are you running 24bit or 16bit?

I like the speed of 16bit. However from what i can understand having 16bit padded input and 24bit data, it will do the conversion and just pad the lower bits of data with 0's. I dont think this gives as good as a colour range as doing a normal RGB565 to RGB888.

I think you can get the pixel pipeline to pull from a 16bit buffer, do the conversion to rgb888 and feed it straight to the lcdbuffer to output (Without needing to do memory to memory)
 
I'm pretty sure eLCDIF can extend 16-bit data to 24-bit on its own, copying the highest bits into the lowest to maintain proper range. The ST7277 datasheet says it upconverts the same way, although I would have doubts on a screen that small having a full 8 bits of range anyway.
 
jmarsh said:
I'm pretty sure eLCDIF can extend 16-bit data to 24-bit on its own, copying the highest bits into the lowest to maintain proper range. The ST7277 datasheet says it upconverts the same way, although I would have doubts on a screen that small having a full 8 bits of range anyway.
Click to expand...

I'm pretty sure it just pads the lowest bits as 0's for each colour. So in the 565 format if you had 5 bits of red, when converted to 888 the lower 3 bits would be 0 (1111 1000)

This is a lot smaller dynamic range then if doing a proper conversion. 5 bits of red should convert to 1111 1111

*edit*

So im wrong, the padding was for the conversion going from 24 bit colour data to 16 bit output.

From the imxrt1062 data sheet

LCDIF_CTRL[WORD_LENGTH], eLCDIF will perform RGB to RGB color space
conversion. For example, if the input frame has fewer bits per pixel than the display, as in
a 16 bpp input frame going to 24 bpp LCD, eLCDIF will pad the MSBs of each color to
the LSBs of the same color for each pixel. If the input frame has more bits per pixel than
the display, for example, 24 bpp input frame going to 16 bpp LCD, eLCDIF will drop the
LSBs of each color channel to convert to the lower color depth
 
I'm not sure what type of content you're displaying but if it's basic stuff that doesn't use too many colors, there's also an 8-bit palette mode (pixels specify a byte index into a 24-bit color palette). It's handy for UIs if you want to support custom colors or simple brightness changes.
 
Calling for the guidance on DB5

I've got an LCD hooked up to elcdif and I wired the LCD Enable pin to a GPIO to turn it on/off in SW
I wired it to GPIO_AD_B1_05 -> GPIO1:21 (pin 65 on DB5) and tried to set it high like so:

Code: 
IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B1_05 = 5; // Set mux to GPIO mode
GPIO1_GDIR |= (1 << 21); // Set as output
GPIO1_DR_SET = (1 << 21);

But the pin stays low, and does not output 3.3v

What am I missing?
 
Nice. Will try it out

I follow your suggestions above regarding polarity for the control signals
But only got a stable image with a 30Mhz pixel clock speed.
Anything lower shows artifacts etc
 
Rezo said:
Nice. Will try it out

I follow your suggestions above regarding polarity for the control signals
But only got a stable image with a 30Mhz pixel clock speed.
Anything lower shows artifacts etc
Click to expand...

So anything lower than 30mhz is giving you artifacts? A lot of artifacts?

I think the data sheet recommends a 25 mhz clock. This gives about a 60hz refresh rate. I've got mine set to 20mhz for a 50hz refresh rate.
 
Rezo said:
lower shows artifact
Click to expand...
What else is 'running' - maybe 30 MHz gets it done without interruption?

st7735 conflicts with Audio (slowed it down to broken) - putting in the SPI end/begin in large xfers as in other libraries cured that - but the constant end/begin broke font drawing on small rectangles as used in fonts.
 
theboot900 said:
So anything lower than 30mhz is giving you artifacts? A lot of artifacts?

I think the data sheet recommends a 25 mhz clock. This gives about a 60hz refresh rate. I've got mine set to 20mhz for a 50hz refresh rate.
Click to expand...
Yep, this baffles me as well.

defragster said:
st7735 conflicts with Audio
Click to expand...
I think you’re confusing the ST7277 which is used in these 7” bare displays (RGB interface) with the ST7735 which is found in smaller SPI based displays
 
@theboot900 here is a comparison of 24mhz (top) vs 32mhz (bottom)

You can zoom into the text on the top left to see interference as well on the middle buttons on the bottom.

I did change pin drive strength as well from 0xFF to 0x10B0 which did improve things a bit

24Mhz
e1508da5-8251-4033-a903-9f3485a8ea9a.jpeg


32Mhz
9f127d5e-6ecd-4427-8565-bdae1932dd87.jpeg
 
You must log in or register to reply here.
Back
Top