• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 446 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C129XNCZAD: TIDM-TM4CFLASHSRAM for TM4C129XNCZAD, slow LCD screen change

Bump This_Post
Prodigy 30 points
Part Number: TM4C129XNCZAD


Hello,

Currently I a close to finishing a device we have been working on for quite awhile. I just cant get past this final problem, the problem being whenever we change screens it takes a noticeably long time for the screen to transition. We are using an external parallel SRAM flash with our 8-bit data being stored on the flash. there is an old DMA transfer function that was changed to take the 8-bit data off of the flash, convert it to 24 bit data, then write that 24 bit data to the SRAM which is acting as our LCD buffer.

  Now there area few other issues I would like to highlight. In addition to this being our bottleneck ( I think) I could not configure the parallel SRAM flash to have the SRAM sit at 0x6000000 and the Flash sit at 0x8000000 and instead had to have our Flash be mapped to EPI_ADDR_RAM_BASE_8 and the SRAM to be sitting at EPI_ADDR_PER_BASE_A. Meaning I DO NOT HAVE our LCD buffer sitting at 0x60000000. I would like to know if this could be causing my issue as well, I have also tried moving it to 0x10000000 with no luck. Now besides those two issues I would just like to get an opinion on how to move forward. I have began configuring uDMA with my plan being to use the uDMA to copy blocks of the pixel data from the flash into internal memory, do the conversion, then use uDMA to move those to the SRAM. I presume this will be much faster than what it is currently doing. Which is copy each individual pixel off of the flash, converting it, then writing it to two different locations on the SRAM. Under normal operation the entire screen is working at about 10hz, when we change screens it takes nearly half a second to complete the screen transition. 

Any advice would be greatly appreciated. If anyone has experience in dealing with type of problem or can point me to another post it would greatly help. I can post more code if asked. Thank you in advanced. 

  • 0
    TI__Guru**** 191906 points

    Hi,

      I have a few comments and questions.

     - Your DoDMATransfer() function seems to use CPU to read data from external flash to the internal SRAM. Is this a correct understanding?

     - How come you are not using the built-in LCD DMA to read from external flash to internal SRAM? Please refer to the datasheet and the peripheral driver library user's guide for details on the DMA usage for LCD. Based on DoDMATransfer(), my impression is that you are using CPU to read the external flash, not DMA. 

     - Your external flash is 8 bit which further slow down the performance. Regardless of using DMA or CPU to read the external flash, reading in 16 bits would have increased your performance by 2x. But this means you will need to change from a 8-bit memory to 16-bit memory. 

     - As described in the datasheet, the preferred configuration is not just to use the built-in DMA for data transfer but also to use ping-pong mode. This will allow new data to be replenished in one frame buffer while the other is being sent to the input FIFO. 

    21.3.2 LCD DMA Engine
    The LCD DMA engine provides the capability to output graphics data to constantly refresh the
    external LCD display, without burdening the CPU, via interrupts or a firmware timer. It operates on
    one or two frame buffers, which are set up during initialization. Using two frame buffers (ping-pong
    buffers) enables the simultaneous operation of outputting the current video frame to the external
    display and updating the next video frame. The ping-pong buffering approach is preferred in most
    applications.


    When the Raster Controller is used, the LCD DMA engine reads data from a frame buffer and writes
    it to the input FIFO. The Raster Controller requests data from the FIFO for frame refresh, so the
    DMA is used to keep the FIFO filled.


    When the LIDD controller is used, the LCD DMA engine accesses the LIDD controller's address
    and/or data registers. The following steps are needed to configure the DMA engine:


    1. Configure the data format in the LCD DMA Control (LCDDMACTL) register, offset 0x040.


    2. Configure frame buffer 0 by programming the LCD DMA Frame Buffer 0 Base Address
    (LCDDMABAFB0) register, offset 0x044, and the LCD DMA Frame Buffer 0 Ceiling Address
    (LCDDMACAFB0) register, offset 0x048

    3. Configure frame buffer 1 by programming the LCD DMA Frame Buffer 1 Base Address
    (LCDDMABAFB1) register, offset 0x04C, and the LCD DMA Frame Buffer 1 Ceiling Address
    (LCDDMACAFB1) register, offset 0x050.\


    In addition, depending on whether the application is operating in LIDD mode or Raster Mode, the
    LCDLIDDCTL or the LCDRASTRCTL register should be configured appropriately, along with all of
    the timing registers. To enable DMA transfers, the DMAEN bit in the LCDLIDDCTL or the LCDEN bit
    in the LCDRASTRCTL register should be written with a 1.

     - 

  • 0 in reply to Charles Tsai
    Prodigy 30 points

    Edit: (I deleted the paragraph below because I accidentally selected that it resolved the issue on accident I am posting it again for posterity )

    The DoDMA function is reading in data from an external flash using CPU memory, then writing it to an external SRAM using CPU memory, currently I am trying to configure the DMA to do that instead. I have inherited this project which is a port of the old device code done by outside contractors. I am in the midst of trying to sort through it all and fix the last few problems it has. I think this was just the planned designed that was pursued because it was assumed there would be no issues with it. I also think they did not want to take the time to configure a palette look up. I will try to use the built in DMA to read the flash, at that point, since it is in 8-bit data format, will I have to configure a palette? I assume I will. I will take my time to try to implement your suggestions I may need further help and I will reply again if I cannot get any further. 

    So to explain further we have all of these symbols and text data located on the flash in different locations, under the current setup the program will use the nested for loops shown above to begin writing the pixel data to the external SRAM, which is our LCD buffer. If i configure the LCD buffer to be the flash how to I get it to switch to different locations on the flash, do I manually change the register values. The current setup we configure the LCDFrameBuffer to be a location in the external SRAM, then for each pixel we access the flash in the loczation needed, convert the data, then write it to that specific frame buffer. If I want to use different locations on the flash in conjunction with the LCD DMA how do I go about doing that? The only Idea I currently have would be to update the LCD frame buffer at the register to each new location. or use the uDMA to write blocks of the flash to the internal memory then to the external SRAM. Additionally our flash stores data in 16 bit format, it is just our pixel data is 8BPP as it is simply copied from an old device. I believe we are using the LCD DMA (as in using a pointer to set the Frame buffer to our external SRAM) because my value LCD0DMABAFB0 is 0xa000'0020, which is the location of the external SRAM.  So to explain further I am using the built in DMA, but we are using the CPU to pull the data off of the flash, convert it, then write it to that buffer pixel by pixel. Any advice on how I should proceed?

  • 0 in reply to Bump This_Post
    Prodigy 30 points

    I only have 256Kb of internal memory, which isn't enough to support an entire frame buffer for a 640x480 screen even at 8 BPP. I can't use uDMA to go from a peripheral to a peripheral. I honestly have no idea how to go about getting the data off of the external flash and into a frame buffer at a faster rate than I currently do.  Currently I plan on using an 8BPP palette, moving the data in Blocks off of the flash using the uDMA, then writing it the SRAM frame buffer.. The internal memory is not larger enough to support a single frame buffer so I am wondering how this is usually handled, do I have to attempt to move my data to the internal flash? I am wondering if anyone else has ran into anything like this or has any other advice?

  • +1 in reply to Bump This_Post
    TI__Guru**** 191906 points
    Bump This_Post said:
    The DoDMA function is reading in data from an external flash using CPU memory, then writing it to an external SRAM using CPU memory, currently I am trying to configure the DMA to do that instead.

    Hi,

      I think I may have given you incorrect information earlier. The built in LCD DMA is used to transfer data from the frame buffer(s) to the input FIFO. The built-in DMA does not handle the transfers from your external flash to the external SRAM. I think what you need is to first move your graphic data from the external flash to the internal SRAM. You would need to use the uDMA to do so. I think what your current setup is to use the CPU to move the data from 'externa' flash to external 'SRAM'. I think if you move the data from external flash to 'internal' SRAM, you will get the performance boost. The internal SRAM is a much faster memory compared to an external SRAM. The internal SRAM is a single-cycle access memory. 

    Bump This_Post said:
    I only have 256Kb of internal memory, which isn't enough to support an entire frame buffer for a 640x480 screen even at 8 BPP. I can't use uDMA to go from a peripheral to a peripheral.

    The reason I was suggesting internal SRAM is to increase the performance since the external SRAM is slow and only 8-bit. I understand the amount of memory to hold a 640x480x8 of graphic data is close to 2.5MB. You might want to split the internal SRAM into two frame buffers where you would move data 128KB at a time from your external flash to one of the frame buffers while the other one outputs the data to the external display. 

  • 0 in reply to Charles Tsai
    Prodigy 30 points

    Thank you I will try that, so because the internal SRAM is so much faster it will have time to move the data with out disrupting the screen visually I understand.. The total size of my binary that I load on to the external flash is 6.4MB, which is less than the 10MB of the internal flash. I will try your method first however I also think I can move the data on the external flash to the internal flash. I also will have to build the palette to use 8BPP but I will have to do that either way. Thank you for the advice! I will try using the internal SRAM as the flash buffer.