Hi,
After initialization and turning the raster controller (RASTER_CTRL.RASTER_EN) on, our LCDC blinks for a brief (<1s) moment during which we could see the CORRECT display of the buffer image, but after that it turns white screen. When the screen is white we could detect correct LCD_PCLK, LCD_VSYNC, LCD_HSYNC, LCD_AC_ENB_CS signals. There are also valid signals on all the 16 LCD_D[15:0] pins, but the screen is just white.
If we immediately (say, within 1s) put new data into the frame buffer (refreshing using CPU writes or EDMA), the display will become normal and show the intended image; if we don’t refresh new data or refresh but not timely enough (say, wait for over 3s before doing that), we will see a white screen and cannot bring the screen back to normal even if we refresh buffer using CPU writes or EDMA later.
Some parameters:
LCDC->LCDDMA_CTRL = 0x00000620; /*also tried double buffer*/
LCDC->LCDDMA_FB0_BASE = FRAMEBUF_BASE0;
LCDC->LCDDMA_FB0_CEILING = FRAMEBUF_BASE0 + (32 + (LCD_WIDTH * LCD_HEIGHT * 2) - 2);
LCDC->LCDDMA_FB1_BASE = FRAMEBUF_BASE1;
LCDC->LCDDMA_FB1_CEILING = FRAMEBUF_BASE1 + (32 + (LCD_WIDTH * LCD_HEIGHT * 2) - 2);
LCDC->RASTER_CTRL = 0x01000080;
LCDC->RASTER_CTRL |= 0x00000001; //already turned on, but white screen still occurs
When the white screen occurs, LCD_STAT reads 00000141h, the lowest bit denoting
LCD_STAT.DONE bit description Raster or DMA_to_LIDD disabled and the active frame has just completed.
Raster or DMA_to_LIDD disabled and the active frame has just completed.
If we update new data (refreshing using CPU writes or EDMA) into the frame buffer immediately, the display will be normal and LCD_STAT reads 00000140h, with bit 0 cleared.
Whether the white screen appears before CPU or EDMA refreshing seems to be related to the image content in the frame buffer. From some real photographs which has different pixel content over its area (and in the buffer array’s memory location), the white screen phenomena occurs; however if we write the full image area of an uniform color like full red (f800h) or full green (07e0h), we will always see this color on the full screen even before CPU or EDMA refreshing. However, LCD_STAT still reads 00000141h with the “DONE: Raster or DMA_to_LIDD disabled and the active frame has just completed” bit set.
We have tested combinations master priority settings between LCDC, EDMA, CPU and VPIF, none solved the problem.
We also verified that the LCD screen itself is in good condition on other platforms. The problems only relates to L138’s LCDC.
The experience of debugging this problem is extremely frustrating, in which have tried all possible combinations of settings, as well as different order and delay between LCD’s driver IC initialization and L138 LCDC initialization, and numerous different image buffer patterns. We have also checked the silicon errata SPRZ301H [2.1.3 LCDC: Underflow During Initialization] problem however LCD_STAT in our problem doesn’t show FUF bit error.
Up to this point we actually suspect this might be another silicon bug of the device. We eagerly and sincerely wish to get answers from TI on this.
John
Hello,
You should try this:
LCDC->LCDDMA_FB0_CEILING = FRAMEBUF_BASE0 + (32 + (LCD_WIDTH * LCD_HEIGHT * 2) - 4);
LCDC->LCDDMA_FB1_CEILING = FRAMEBUF_BASE1 + (32 + (LCD_WIDTH * LCD_HEIGHT * 2) - 4);
as addresses are defined in 32-bit words.
Jakez
Jakez,
We modified accordingly, but it didn’t solve the problem.
In fact, -4 or -2 in the formula result in the same register value. The last hex bit of the ceiling register can only take 0, 4, 8, C four values. Because FB0_BASE and FB1_BASE is also aligned on 32-bit words, and that
32 + (LCD_WIDTH * LCD_HEIGHT * 2)
Is also multiples of 4, so in the last there would be no difference if we -4 or -2. If we compare -2 with -4, the extra two due to -2 will be ignored since only 4’s multiples of bytes (32-bit words) are accepted.
Is there any other possible cause of the problem?
In fact, the
formula was taken from file
// \file evmomapl138_raster.c
// \brief implementation of the raster LCD driver for the OMAP-L138 EVM.
In a “bsl” (board support library) folder which should be originated from TI. I tend to believe -4 and -2 have no difference here.
All is like video data were sent only for one or a few frames then halted (a basic TFT screen keeps image a few seconds if not refreshed), that's what the LCD_STAT_DONE bit says.
Other low-cost suggestions / verifications, assuming LCD_STAT_FUF is 0, and all other configuration registers ok:
- In my implementation of a TFT display (which works), bit 24 of RASTER_CTRL (STN_565) is 0 (only used in STN mode, but...).
- Dot frequency: must be < 37.5 MHz
- Is bit 0 (RASTER_EN) of RASTER_CTRL really still set when LCD_STAT_DONE is set ?
The RASTER_CTRL. STN_565 field description says:
SPRUH77 24.3.3 LCD Status Register (LCD_STAT) 12-Bit-Per-Pixel (5-6-5) Mode. This is only available in passive-color (STN) mode when 12 BPP is specified in the palette.
12-Bit-Per-Pixel (5-6-5) Mode.
This is only available in passive-color (STN) mode when 12 BPP is specified in the palette.
So in TFT mode I wonder if this bit is simply ignored? I have made it 0 and the display is still the same when it is set to 1, so that you could have your screen works finely perhaps cannot be attributed to this bit being cleared.
In our white screen case, The RASTER_CTRL.RASTER_EN bit is also set when LCD_STAT.DONE is set, and FUF is always cleared. LCD_PCLK is in fact smaller than 10MHz.
After deeper reading in the docs, the 2 least bits if base and ceiling registers are hardwired to 0 (-2, -3, -4 offsets are the same). The STN565 bit is not intended to be used in TFT mode (just for trying).
No more suggestions, but some questions (more data required):
Can you clarify the sentences
"we immediately (say, within 1s) put new data into the frame buffer (refreshing using CPU writes or EDMA)" ? Do you mean you simply transfer data to video buffer or you do LCDC registers reprogramming too ?
"There are also valid signals on all the 16 LCD_D[15:0] pins, but the screen is just white." Do you mean LCD data line toggle while LCD_STAT_DONE is set ?
Just to be sure, can you display us all the LCDC registers values, and the palette data ?
In which memory is the video buffer located ?
Sincerely thanks for sparing time on helping us!
Jakez "we immediately (say, within 1s) put new data into the frame buffer (refreshing using CPU writes or EDMA)" ? Do you mean you simply transfer data to video buffer or you do LCDC registers reprogramming too ?
Simply transfer data to video buffer, either use CPU direct programming or EDMA3.
Jakez "There are also valid signals on all the 16 LCD_D[15:0] pins, but the screen is just white." Do you mean LCD data line toggle while LCD_STAT_DONE is set ?
Yes, LCD_PCLK, LCD_VSYNC, LCD_HSYNC, LCD_AC_ENB_CS are all toggling while LCD_STAT.DONE is set, and on LCD_D[15:0] we also see toggling signals.
Jakez In which memory is the video buffer located ?
DDR2, starting from 0xc1000004.
The registers and palette are as below:
John,
For sure it's a strange one...
'Checked the registers value:all seem fine for a 240 columns x 320 rows display (specific display timings / signal polarity to be checked ?)
're-checked my LCDC while halted: the LCD_STAT.DONE bit always keeps reset (as expected). Except for int enable flags, the registers in my configuration are quite the same. Note that in the init sequence, the RASTER_EN bit is reset prior other registers (re)configuration. Other minor differences for information: LCDDMA_CTRL.TH_FIFO_READY=5 (256 dwords), LCDDMA_CTRL.BURST_SIZE=4 (16 dwords), 800x480 display.
'Palette data ok
If signals are toggling, the display module shouldn't be white except if false timings, false sync polarity, bad connection,.... Is the hardware a validated one (EVM,...) or a prototype ? Have you tried the software with another same board ?
Silly suggestions:
- The CPU reset and set RASTER_EN somewhere
- The other CPU reset and set RASTER_EN
We will provide a package containing the code that leads to the problem. Since the LCD_STAT_DONE problem is internal to the OMAP L138 chip is doesn’t require an external LCD player to manifest itself, so the problem can be reproduced and diagnosed. Please allow us some time!
The cause has been found and L138 did not cause the problem. Even if we have seen LCD_STAT_DONE error bit set, this does not prevent the LCDC from outputting correct signal, so the LCD screen should at least output something. The problem was due to a loose GND solder joint and manifests in the following situation:
For images of normal brightness, if we refresh buffer “timely” after LCDC initialization, the display would be fine. If we don’t refresh timely enough, the LCDC driver IC’S charge pump voltage output oscillates strongly before finally losing its output voltage level, and the screen turns white.
For very brightness images, for example a full screen of 0xFFFF (white), LCDC driver IC’s charge pump would always lose its voltage level regardless of the manner LCDC frame buffer is refreshed. According to the driver IC’s datasheet higher voltage level is required for brighter images.
Though the GND joint was not well soldered, darker image requires lower voltage and current, so if the refresh was “timely” enough, due to some mechanism the images could still get displayed; if the image is brighter and requirement on voltage and current is higher, the problem just always manifests.
This problem after all is really very tricky to find and we did lots of cause elimination until finally identified it. After having a solderer re-solder the joint it works out without problem.
Sorry for taking you so much time for looking into the case, your input is very helpful in helping us to dig out the case.