Would like to report some problems that appears to be the limitation of LCDC DMA capability.
First is regarding a bit “LCDEN” for enabling DMA transfers, documented in L138 TRM SPRUH77 page 1000, 1001, 1035 (page might differ across revisions but ) for a total of 5 times, yet it is not found in any register field. I suspect it might be a typo in the TRM. It appears that the LCDC’s bandwidth is extremely limited:
1. First, when Ping-Pong buffering is used, I use a slightly modified version of the L138 Starterware to update frame buffer content. This is just by CPU writing and naturally very slow: a 200-by-200 image would need several frames’ time to complete. For images of dimensions like this, even double-buffering could not eliminate the apparent visual artifacts that the image was being drawn across several frames.
2. Since the intended application has a higher expectation on visual appearance and we do not wish to see artifacts like above during ping-pong buffer updates, we decided to use EDMA3, and chose the straightforward AB synchronization. It works fairly well for moderately-sized images of like 16000 pixels (around 130 by 130). However, for larger size EDMA updates like 200 by 200, EDMA3 seems to disrupt LCD DMA operation and would result in displaced screen. The effect is exactly like that the origin has been moved away from (0,0) to another location (like (50,50) ) and the screen got wrapped bottom-to-up and left-to-right.
a. An immediately cure to the displacement problem is by turning off raster controller during frame update, and turns it on after update has completed. We achieved this using:
LCDC->RASTER_CTRL &= ~0x00000001;Update frameLCDC->RASTER_CTRL |= 0x00000001;
However, it is apparently an “insecure” and imperfect approach since in theory the LCD screen would have flash “white” and then back to normal, although in practice we didn’t see this effect with a fresh rate at 60Hz. Nonetheless, after turning on raster controller again it seems defaults to output frame buffer 0 even when it should output frame 1, and frequently we could see flashing artifacts that we suspect might owing to this.
b. As we have mentioned above, with smaller size images updated by EDMA the displacement artifact doesn’t happen. We therefore suspect that the EDMA3’s competition with LCDC DMA on DDR2 access might have caused the artifact. We check LCDC status register every time a displacement artifact happens:
LCD_STAT: 0x00000344: end of both frame detected + palette loaded + Frame Synchronization Lost has occurred.
We tried to mitigate the problem using ensemble of the following approaches:
I. Tuning LCDDMA_CTRL.TH_FIFO_READY and LCDDMA_CTRL. BURST_SIZE. We found that if both are set to their maximum (512 dwords, and burst size of 16), the screen would show a full of screen of uniform dark green color with the following LCD_STAT value:
LCD_STAT: 0x00000060: The palette is loaded + LCD dither logic not supplying data to FIFO at a sufficient rate, FIFO has completely emptied and data pin driver logic has attempted to take added data from FIFO
The FIFO empty message is not a surprise as we have set the FIFO threshold to 512 dwords. Intermediate values for LCDDMA_CTRL.TH_FIFO_READY and LCDDMA_CTRL. BURST_SIZE does not cause extreme problems like this but could displacement issue still exists.
II. EDMA3 fragmentation.
1) First, according the first example of Example 18-4 in EDMA chapter (page 593), we split the original continuous source into even and odd parts and transfer them in two pass, in order to prevent the EDMA’s default optimization like the example shown: ACNT = 8, BCNT = 8 optimized to ACNT = 64, BCNT = 1.2) We also attempted to reduce burst size according to instructions at page 592, 18.104.22.168.1 EDMA3TC Configuration. However, the documents says that only DBS (burst size) can be changed. However the option in CFGCHIP0 and CFGCHIP1 allows only increasing burst size from 16 bytes to 32 or 64 bytes, apparently contrary to our will of decreasing it.3) Trying to “reroute” the traffic so that EDMA3 and LCDC DMA goes through different SCR parts. We examine the colorful Figure 4-1. System Interconnect Block Diagram without finding a possibly better configuration:
All three transfer controllers (EDMA3_0_TC0, EDMA3_0_TC1, EDMA3_1_TC0) access DDR2 via SCR1 and SCRF3, and LCDC also access DDR2 via SCRF3, so they both have to pass through SCRF3. We found no way to change this.
4) Assigning a different part of memory to at least one of the two LCDC ping-pong buffers. However according to Table 4-1. OMAP-L138 Applications Processor System Interconnect Matrix, LCDC can only access DDR2 so this approach is also inapplicable.
We have no idea why the displacement error could happen; and regarding one of the LCD_STAT values above, why frame synchronization could have lost? And why turning off and on raster controller could some cure the displacement problem much like doing a “reset.”We also want to get advices from TI experts on how the displacement problem could be solved. After all, has there been any successful application of L138 in which ping-pong update of probably the entire frame buffer content does not cause displacement like we described?
Summarizing what I have understood:
- You want to refresh screen only after having computed a new complete image, you use a dual-buffer technique with LCDC (automatic buffer commutation at each frame)
- The image computation rate is lower than the screen frame rate, so you decided to use EDMA3 to copy a new computed image to the next frame buffer,
- The use of EDMA3 now generates displacement and out-of-sync effects
Suggestions if the above is true (and perhaps even in the other case):
- A raise of the LCDC master priority may be required (should be higher than the EDMA3 controller you use, it is lower at reset) : the displacement effect probably derives from a LCDC FIFO empty event.
- Simplify the problem: use an alternate frame buffer commutation technique by managing LCD DMA Frame Buffer 0&1 registers at end of frame interrupt (a little tricky, but avoids useless buffer copy)
- By disabling the LCDC controller, the transmission to the LCD screen is stopped. If it is a TFT one, it may keep the image displayed a few seconds (degrading in time) through the pixels capacitors, then explaining the absence of noticeable image perturbation before re-enabling the LCDC after the copy to the frame buffer.
To answer your last question, I faced the same low rate full image clean update problem and finally (successfully) used a triple-buffer technique by managing LCD DMA Frame Buffer registers on a 800x480x60 Hz 16-bit TFT display. A high LCDC master priority was essential (other long transfer masters in the system).
Jake's suggestions are great!
JakeZ- A raise of the LCDC master priority may be required (should be higher than the EDMA3 controller you use, it is lower at reset) : the displacement effect probably derives from a LCDC FIFO empty event.
JakeZ- Simplify the problem: use an alternate frame buffer commutation technique by managing LCD DMA Frame Buffer 0&1 registers at end of frame interrupt (a little tricky, but avoids useless buffer copy)
JakeZ- By disabling the LCDC controller, the transmission to the LCD screen is stopped. If it is a TFT one, it may keep the image displayed a few seconds (degrading in time) through the pixels capacitors, then explaining the absence of noticeable image perturbation before re-enabling the LCDC after the copy to the frame buffer.
JakeZTo answer your last question, I faced the same low rate full image clean update problem and finally (successfully) used a triple-buffer technique by managing LCD DMA Frame Buffer registers on a 800x480x60 Hz 16-bit TFT display. A high LCDC master priority was essential (other long transfer masters in the system).
Some additional information:
Perhaps you should reserve the priority 0 for the CPUs (for example LCDC priority to 1 and the EDMA3 TC you use to 2).
The basic TFT controller continuously store voltage in screen pixel capacitors. Stopping sending information to the controller only makes the capacitors slowly discharging to zero, which is not harmful by itself. However a specific module may implement auto standby function with power supply shutdown for example; frequent on/off could then rapidly lower reliability.
I have tested that. Even for videos of quite large size get updated through EDMA smoothly without any artifact. Thanks a lot for suggestion.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.