• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 31 subscribers
  • Views 2507 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TM4C129LNCZAD: Mass LCD underflow interrupt will let LCD module abnormal with external SDRAM as the LCD Buffer

LEI YAN
Expert 3750 points
Part Number: TM4C129LNCZAD

Hi e2e,

Our customer meet a problem in TM4C129LNCZAD with external SDRAM(EPI bus) using as the LCD graphic buffer, they system is working as below described;

1. External SDRAM is using as LCD graphic buffer, and also used for user application buffer at the same time;

2. LCD module will read graphic buffer via DMA regularly;

3. MCU will have burst R/W to SDRAM in some condition, it will occupy EPI bus at this time, if the EPI bus is hold for a long time, LCD underflow interrupt will generate a lot;

4. sometimes the LCD module still work fine while some LCD underflow interrupt generated, but if the interrupt is too much in a short time, the LCD module won't work anymore, it means it can not recover and transmit data from SDRAM to LCD module in DMA, LCD display will be in abnormal with mass color in display, and finally going to white;

they also did a test to easily repeat the issue, if they put the system heap into SDRAM, the issue will repeat frequently, and currently they are putting the heap in internal SRAM.

Do you have any suggestion in their application? and is there any way to keep the LCD module alive even there are many LCD underflow interrupt generated.

thanks.

LEON

  • 0
    TI__Guru 72500 points

    Hi Leon,

    Leon_ee_yan said:
    is there any way to keep the LCD module alive even there are many LCD underflow interrupt generated.

    I suspect that question would be better answered by the LCD vendor.

  • 0
    TI__Guru**** 244380 points
    Hello Leon

    There is a known errata with LCD. The errata number is LCD#03. There is a bit to restart LCD on underflow. However due to a design limitation, the bit does not work as expected. The only other suggestion would be to access SDRAM during the Vertical Sync or End of Frame interrupt.
  • 0 in reply to Amit Ashara
    Guru 117855 points

    Sometimes - inefficient/improper "MCU to Display program code" - will "slow" the Display "update" - and cause such condition.

    The fact that the display (sometimes) works indicates that the "extra demands" - imposed by EPI Bus being "held" excessively - argues for the determination (via measurement) of just what constitutes, "excessive hold time?"      That's not mentioned here - and may warrant (some) consideration.     Armed w/that "target" - a fixing strategy may be deployed...

    One here suggested contacting the display vendor - might a parallel contact of the memory vendor - also prove useful?

  • 0 in reply to Amit Ashara
    TI__Expert 3750 points

    Hi Amit,

    is it possible to configure the bus priority to let LCD DMA working in a higher priority while accessing external SDRAM?

    thanks.

    LEON

  • 0 in reply to LEI YAN
    TI__Guru**** 244380 points
    Hello Leon

    When accessing the SDRAM, the LCD-DMA has the highest priority. However if the CPU is already accessing the SDRAM during the break between LCD-DMA access, then the LCD-DMA will be stalled. What is the size of the transfers being set for the LCD controller configuration?
  • 0 in reply to Amit Ashara
    TI__Expert 3750 points

    Hi Amit,

    they checked and the size is 1024.

    and i asked them did a test about "LCD#03", if they do not run "LCDRasterEnable()" while Underflow Occurs, LCD will failed to display immediately.

    in their current software, they already implement "LCDRasterEnable()" while Underflow Occurs, but they found if a lot of Underflow Occurs, the workaround will fail, and the phenomena will happened as 1st post described.

    why the "LCDRasterEnable()" workaround has the limitation in this condition?

    thank you.

    LEON

  • 0 in reply to LEI YAN
    TI__Guru**** 244380 points
    Hello Leon,

    The Burst Size has 3 values: Burst of 4, 8 or 16. I do not see the burst size of 1024?

    Did they try to disable the LCD Controller and then enabling it, i.e Clearing the underflow condition, and then LCDRasterDisable followed by LCDRasterEnable?
  • 0 in reply to Amit Ashara
    TI__Expert 3750 points

    Hi Amit,

    the burst size is 16, and for your suggestion, we will do the testing and reply later.

    thanks.

    LEON

  • 0 in reply to cb1_mobile
    Guru 117855 points

    cb1_mobile said:
    Sometimes - inefficient/improper "MCU to Display program code" - will "slow" the Display "update" - and cause such condition.

    Improper "burst size" clearly fits w/in that "inefficient/improper MCU to Display program code" identification.

    And - with absolutely "no mention" of the display's "pixel resolution" - wheels here may (further spin!)      The EPI of this MCU has limited ability to support "pixel rich" displays - and that limit may have been surpassed...