• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 1125 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.

CCS/DK-TM4C129X: Screen initialization problem

Clara Mongold
Prodigy 20 points
Part Number: DK-TM4C129X
Other Parts Discussed in Thread: BQ35100

Tool/software: Code Composer Studio

Hi,

I use the DK-TM4C129X for development and I have a problem with the LCD screen. After a certain period of running (6 hours), the initialization function " Kentec320x240x16_SSD2119Init " of the screen does not want to be executed and the screen remains blank. So I can not continue to display my data on the screen. If I disconnect the screen for a few hours, it resumes operation and my code runs again. Do you have any idea where the problem can come from? Is it my code or the hardware ? Does the display have a limited number of hours of running ? Below my code :

int

main(void)

{

// Run from the PLL at 120 MHz.

g_ui32SysClock = SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ | SYSCTL_OSC_MAIN | SYSCTL_USE_PLL | SYSCTL_CFG_VCO_480), 120000000);

// Initialize the display driver.

Kentec320x240x16_SSD2119Init(g_ui32SysClock);

// Initialize the graphics context.

GrContextInit(&g_sContext, &g_sKentec320x240x16_SSD2119);

// Initialize the sound driver.

SoundInit(g_ui32SysClock);

SoundVolumeSet(230);

SoundStart(g_pi16AudioBuffer, AUDIO_SIZE, 64000, SoundCallback);

// Initialize the touch screen driver and have it route its messages to the widget tree.

TouchScreenInit(g_ui32SysClock);

TouchScreenCallbackSet(WidgetPointerMessage);

// Introduction Presentation and Screen

TIWelcome();

InitWidget();

Measures_Board();

}


Thank you for your help

Best regards

Clara Mongold

  • 0
    Guru 117855 points

    Your "subject/title, Screen Initialization Problem" is to my mind - off mark.

    Are you sure that the issue is (entirely) w/in the display?     How do you (really) know?      And how do you relate this to "initialization" - especially as the screen "Works for hours?"    (surely "freeing" initialization from suspect status!)

    Instead - "IF and only IF - you've fully/properly monitored (both) the bus & strobe activity (MCU -> Lcd) during that "entire initialization sequence" - and the screen (remains) blank - does "initialization" become questionable.    Your writing does not include such detail.

    Use of a regularly toggling Led can serve as 'test/verify" of your MCU's "continued" functionality.       (it is unwise to "assume" that proper MCU operation is (always) the case - even when - and especially when - the MCU is yours/your firms!)       (blasphemy - I know)

    Unstated is the usage & "transaction factor" between MCU & display - during the entirety of that six hours.     If data is continually being sent to the display - and the display is NOT becoming over-heated - or otherwise stressed - I'd bet upon some "transaction irregularity" causing the display to blank.

    If heat is suspected - would not a simple temperature sensor - attached to the display's (likely) "hot-spot" - and regularly monitored - guide you to a solution?

    Firm/I have past been in the display field - unless stressed beyond spec. - no such "limited time display operation" has been noted...   (assumes a properly functioning display - have you verified this "condition" upon a 2nd display?)      That would be worthwhile - don't you agree?

    Prototype connections are ALWAYS suspect - even slight heat build-up may disturb/distress.      

    Might your "investigation" be (somewhat) expanded - to systematically include the (likely) paths - herein detailed/suggested...

  • 0 in reply to cb1_mobile
    TI__Prodigy 20 points
    Thank you for your reply. I'm sorry if my explanation is not detailed enough but your reply helps me understand some of my problem.

    I have already tested a few investigations that you suggest :

    - I did not notice any overheating of the screen- or otherwise stressed

    - I tried with another TM4C129x development platform and the same problem appears

    - The MCU still functions because if I only comment the "display on screen" of my code, the rest of my code runs (I use this MCU to do battery monitoring with BQ35100 and display the results on the screen). I suspect that the issue is in the display because if I execute the code step by step (mode debbug), the execution remains blocked on the function "Kentec320x240x16SSD2119Init". This problem only occurs after a few hours of functionning. If I disconnect the TM4C129x for a few hours, the screen initialization is done correctly and the code runs normally. But since my code is still in development, the display on the screen does not happen continuously and data is not continually being sent to the display. So I guess my problem arises from irregular transactions causing a display to blank.
    When my project is finished and the data will be sent out regularly, I will monitor if the problem persists. In this case, I will contact you.

    Thanks a lot for your help
    Best regards
    C.M
  • 0 in reply to Clara Mongold
    Guru 117855 points

    Thank you - your detailed response much appreciated. (and greatly assists such "remote" diagnosis)

    Over many years - past firm/I have produced/sold/shipped well over 100K (similar) displays - rarely noting such a "fail w/operating time" issue. Anything is possible - yet I'd blame the MCU code (or signal glitch) first - the display "far down the list."

    I did suggest that you employ a second Display - that would provide (far greater) "proof" of a potential display issue.

    Any imperfect connection - anywhere upon the MCU -> Display interconnect - may invite a signal glitch - which (may) "latch up" the display.

    You note that the display "recovers" after a "few hours." May I suggest that you (instead) test after (just) 10-15 minutes after Power Down?

    And most critical - if your program execution "blocks upon a function" - that is a strong indictment of the code! (a possible exception is if the code must execute a "read" from the display - and "hangs" due to that "Display -> MCU" signal's "non-arrival.") You may wish to review the init. code - and see if any such "two way" data exchanges (or even strobes) are "in the mix."

    One more point - the display you've noted has undergone change - earlier ones (iirc) employed parallel bus - newer ones moved to SPI.      Code changes surely followed!      How sure are you that your code BEST MATCHES the unique Display which you have?     

    And - it is always wise to report such issue to the display vendor - they have the "maximum awareness" of any such Display issues - and (often) successful "work-arounds."