4
\$\begingroup\$

hardware configuration

Application details:

  • SDRAM is used as the LCD frame buffer.
  • Memory for 2 LCD frame buffers are allocated(double buffering) in SDRAM. LTDC will be always accessing one of the frame buffer in the SDRAM for updating the frame. The new data(which is to be shown in next frame) will be updated in the other frame buffer area which is not being used by LTDC at that instant.
  • I am storing all the static images in NOR flash.
  • My application needs simultaneous access to SDRAM and NOR flash which is supported by the controller(I am using STM32F429 silicon version 3).

Issue: Whenever the application executes a copy operation from NOR flash to SDRAM , FIFO underrun error occurs in LTDC and the images in LCD are getting distorted for some time. I got to know that LCD controller is denied SDRAM access for a time, long enough for the LCD FIFO to become starved.

• I tried reducing the LCD clock then the images are getting displayed without any distortion. LCD’s typical working frequency is 30 MHz . If the frequency is reduced I am seeing some dimming in LCD. From LCD datasheet it will take 18.29 ms to update one frame in LCD at 30 MHz LCD clock. i.e., frame rate will be 54.65 fps. At 24 MHz LCD clock, it will take 23.1 ms to update one frame in LCD . i.e., frame rate will lower to 43.29 fps. I would like to keep our frame rate above 50 Hz. The contents of SDRAM and NOR flash are verified and found to be valid.

SDRAM_CLOCK_PERIOD used = FMC_SDRAM_CLOCK_PERIOD_2 ( 2*Thclk) ( HCLK = 168 MHz)

• When the LCD frequency is increased to 40 MHz in ST evaluation board, we were able to find same issue.

It is taking more time to copy an image from NOR flash to SDRAM in my custom board compared to evaluation board.

Queries:

  1. Even though same FMC configuration is used in both boards, time to copy from NOR to SDRAM was more in my custom board. Is it because the SDRAM data bus is just 16 bits? Can I resolve the issue if I use an SDRAM with 32 bit data bus?
  2. What is the maximum frequency in which LCD can be operated in this configuration ? (simultaneous access of SDRAM by both LTDC and NOR flash).
  3. How can we measure the actual time required to copy from SDRAM to LTDC controller?
\$\endgroup\$
  • 1
    \$\begingroup\$ Perhaps you can perform your flash-to-SDRAM copy in multiple blocks rather than all at once, and give the LCD painting functionality a chance to get in there in between. Appropriate block sizes and synchronization would probably require studying details of all of the systems - NOR flash timing, LCD fetching operation, and the bus arbiter or whatever is scheduling these things. \$\endgroup\$ – Chris Stratton Dec 3 '15 at 7:20
  • \$\begingroup\$ you mean I need to cache all the images which will be used in application to SDRAM before start. Yeah, this is a work around, but It may restrict the no of images used because of SDRAM size limitation. \$\endgroup\$ – kernel Dec 3 '15 at 7:35
  • 1
    \$\begingroup\$ No, that is not what I said at all. Rather, if you need to copy something big from flash to ram, rather than doing it in one operation split it into pieces and give updating the LCD some memory bandwidth in between, in order to keep that fifo from running empty. Perhaps what you really should do though is figure out a way (possibly with a logic analyzer?) to profile what is happening. \$\endgroup\$ – Chris Stratton Dec 3 '15 at 7:36
  • \$\begingroup\$ Ok. got it. But I am using DMA_2D to copy an image from NOR flash to SDRAM. So splitting that copy will disrupt the entire software configuration as this is controlled by third party library (touchgfx). \$\endgroup\$ – kernel Dec 3 '15 at 9:24
  • \$\begingroup\$ I tried asking ST support but they told that they don't have this kind of information. \$\endgroup\$ – kernel Dec 3 '15 at 9:27
1
\$\begingroup\$

I had a similar issue, which I solved with the help of ST's tech support. The solution for me was to put the two frame buffers in different banks of SDRAM. I think the SDRAM I'm using, and I guess maybe all SDRAM, is designed to perform optimally when reads/writes on any given bank are contiguous blocks. Putting the frame buffers in different banks means that they are accessed in this optimal way by the STM32, allowing the memory to keep up with the FIFO's needs.

\$\endgroup\$
1
\$\begingroup\$

I also had this issue using an STM32F767 driving a 800x480 color LCD, also using concurrent DMA2D transfers into the framebuffer with only one bank of SDRAM available. I solved it by running the SDRAM as fast as the data sheet would allow (HCLK at 168MHz) and slowing down the LCT-TFT clock to 20MHz. My LCD brightness still looks okay to me at this slower rate. Thanks for starting this post that led me toward this solution!

\$\endgroup\$
  • \$\begingroup\$ Jenson I too solved the same way. But unfortunately my LCD hardware brightness is below than expected when frequency is under 23 MHz. So had to change the SDRAM to 32 bit . This also provided flexibility to cache more images so that it provides faster animation . \$\endgroup\$ – kernel Feb 23 '17 at 3:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.