STM32F746 LTDC: 1) blinding instead of blending 2) noise lines

[Eugene Solo]

Posted on April 01, 2017 at 21:41

1) Probably its only my misunderstanding, but here is a problem:

Layer1 have same size and viewable area of display (800*400), pixel format L8 (with CLUT, ofc). I'm planning to put GUI there - occasional partial redraw of small areas (text, icons, indicators, so on).

Layer2 have size about 500*200 pixels and located inside viewable area, pixel format AL88. I was planning to use it for spectrum display - periodic redraw of full layer. I thought to place grid for spectrum to that area on Layer1 under Layer2, so blending will 'mix' image of spectrum and image of grid to one nicey shiney picture.

But I found out that its not working. 'Default color' of Layer2 (LTDC_Layer2->DCCR) completely covers underlaying layer, and it does not respect its own alpha settings. Ofc, i can set layer' constant alpha, but this makes both layers less juicy. I tried color keying: LTDC_Layer2->CKCR = 0; LTDC_Layer2->CR = LTDC_LxCR_CLUTEN | LTDC_LxCR_LEN | LTDC_LxCR_COLKEN; - so black color should be color key. Nop, didnt work, same screeening. So layer2 can completely screen Layer1, even if its only 1x1 pixel size.. i dont understand point of this mechanics.

Is it possible to make only part of layer to be opaque while rest of it stays transparent? Is it possible with AL88 pixel format? I want to save SDRAM bandwidth for some other tasks too

2) when both layers are visible (constant alpha is about 128 for Layer2 - so its stays visible and so do Layer1) I see small vertical lines near painted areas (clear screen and some colored areas just to see whats going on), those lines consist of random colored pixels, looks like noise. I dont think that this is memory issue or LTDC starving for data - pixel clock is only 36 MHz, memory works on 108 MHZ and its 32-bit wide. Horizontal distance between those lines looks very suspicious - i'm not sure, but it looks like 64 pixels... what can be wrong with it? Im absolutely sure that this is not oscillations on bus or something physical.

#ltdc #stm32f746

[markus239955_stm1_stmicro_com]

Posted on April 02, 2017 at 08:43

The document AN4861 is pure gold to optimize the LTDC:

http://www.st.com/resource/en/application_note/dm00287603.pdf

 

With 2 Layers and 800x480 pixel, you can generate a lot of hickups if the settings of memory access

is not perfect. See the document for more infos. Keep the burst lenght to 1 transfer is the most important advice from my side to avoid screen distortion.

Best regards,

Markus

[Eugene Solo]

Posted on April 03, 2017 at 06:55

I have another LCD, 480x272, effect still visible. Pixel clock is 12 MHz (3 times lower than with bigger screen). But this is lesser problem, main is 'why color key is not keying or where i was wrong in my understanding of blending'

[markus239955_stm1_stmicro_com]

Posted on April 03, 2017 at 20:24

Did you read the AppNote ?

Can you add a screenshot ?

Which color format for the layers are you using ?

Which color format have your graphics ?

Which Board do you use ?

How are your project settings ?

I do not want to perform an educated guess !

[Eugene Solo]

Posted on April 03, 2017 at 20:43

Did you read the AppNote ?

It was my starting point, appnote and RM.

Can you add a screenshot ?

you mean photo? yes, but not very detailed

Which color format for the layers are you using ?

That was mentioned in subj. Did you read it?

Which color format have your graphics ?

?? what graphics? its just framebuffer. Memory region mapped to screen area. You writing to this memory and LTDC projecting its contents to LCD bus according to timing settings and stuff. And its working ok: simple square frame with (255,255,255) color pixels looks great -  no visible jitter, no random pixels. Seems that problem appears when any of color components (only one, two or all three) switching from 0x7F to 0x80 code. If its switching from bigger code to lesser code, threshold is different, but still there - if I draw two rectangular areas, one willed with gray (127,127,127) color and another with (128,128,128), you can cleary see the line of random pixels between them. It may look like ground bounce, but its not ground bounce - board have solid ground plane.

And its not memory glitch too: memory was tested, every single byte, half-word and word with different patterns. I had successful linux boot too, it worked without any memory faults.

I've tested with different sync and clock polarity settings, nothing helps to improve picture. And i'm out of guesses already.

Which Board do you use ?

my own design, 64 megabytes of SDRAM, 32-bit wide bus running on 108MHz

How are your project settings ? I do not want to perform an educated guess !

what settings do you need? memory map? libraries? -softfloat or -hardfloat? Code is in flash, stack in internal SRAM, heap is in external SDRAM (not used yet, its just planned to be there)

[Eugene Solo]

Posted on April 03, 2017 at 21:26

brightness decreasing: two glitches, i guess one on 3/4 and another at 1/4 brightness; and one particular red channel glitching;

whole screen, you see those vertical glitches are on same positions for all 3 color channels

brightness increasing: one glitch exactly at 1/2 brightness

whole screen

[Eugene Solo]

Posted on April 03, 2017 at 23:45

well, huh, those nasty electrons... MCU, LCD and my code are proven to be innocent!

I've changed all ceramics around LCD pins and memory bus and voila, magical dissapearance of bus glitches - they all are gone.

But question about blending is still there.

How to use this feature? how do i properly set fully transparent color for top layer to make bottom layer partially visible?

[markus239955_stm1_stmicro_com]

Posted on April 04, 2017 at 21:30

>what settings do you need?

the config of LTDC and Layers, we are discussing TFT display problems. I attached my layer settings for 800x480.

>SDRAM ... running on 108MHz

all STM32F7 allow SDRAM clock up to 100 MHz, you managed to get it stable at 108 MHz, congrats,

but all reference software/hardware from ST insists to use 100 MHz max for SDRAM and to downclock the uC from 216 to 200 MHz.

for blending, did you try ARGB8888 for the layer settings ? It does not need to match to the TFT output settings.

Display glitches can occur even if the memory is read correctly during a memory test. It is not the case that a false value is read, but it is not read at the moment when it is needed to feed the data stream to the LTDC. Than a buffer underrun will occur. Did you activate the IRQ for LTDC to monitor any errors ?

For example, on my STM32F429i-disco, the VGA output showed massive distortions during a data transfer from SDcard to SDRAM because the data transfer from SDIO to SDRAM blocked the access of LTDC to feed the video stream. Fixed it with a burst line of 1, which is slower, but ends befor LTDC needs the next pixel data.

[Eugene Solo]

Posted on April 05, 2017 at 01:18

all STM32F7 allow SDRAM clock up to 100 MHz, you managed to get it stable at 108 MHz, congrats,

but all reference software/hardware from ST insists to use 100 MHz max for SDRAM and to downclock the uC from 216 to 200 MHz.

I know that clock for SDRAM can be HCLK/2 or HCLK/3, but I dont know about such restriction. And 108 or 100 MHz is not so big difference. I have tuned FMC with respect of timing parameters, they all are in acceptable ranges for MCU, so i dont see why it can't work. Thorough RAM testing did not detected any problems with it.

for blending, did you try ARGB8888 for the layer settings ?

as I mentioned it before, Layer 1 is L8  and Layer2 is AL88

Blending works for whole layer, that is good, but i can't see effect from color keying. It is enabled, but seems that its not working if color key is same as default key, which is pretty weird.