• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 30 subscribers
  • Views 1315 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.

CCS/TM4C1294NCPDT: SysctlReset()

Shyam Shankar
Prodigy 220 points
Part Number: TM4C1294NCPDT

Tool/software: Code Composer Studio

Hi,

I have interfaced an LCD with the TM4C1294NCPDT . 

Without using TI RTOS, when I reset the processor using SysCtlReset(), upon Interrupt by a Switch press SW1, the program execution resumes as normal and the LCD displays as normal.

But when I use TI RTOS, and program the same functionality, the LCD gets corrupted upon execution after SysCtlReset().

Does anyone have any idea as to why this occurs?? 

I have checked the LCD initialisation code, but it seems to be correct.

Thank You.

  • 0
    TI__Guru* 96960 points
    Hi Shyam,

    Is the SysCtlReset() working properly (e.g. the device is being reset). Do you get back to main() after the reset?

    Todd
  • 0
    Guru 117850 points

    Shyam Shankar said:
    the LCD gets corrupted upon execution after SysCtlReset().

    This suggests that there (likely) exists (some) difference between the handling and/or timing of that function's execution - from w/in your 2 sources.

    You don't describe the  Lcd's "corruption" - yet that most often provides strong diagnostic aid.     We must assume that the (existing) Lcd image does not "fully clear" - or otherwise becomes incomplete and/or distorted.    Is this correct?

    Unknown is if an "external Lcd Controller" is being employed.    If so - the RTOS may be impacting the correct initialization of your Lcd's controller. If you are employing the MCU's  "EPI" - its (involved) set-up & config. - may not have fully/properly completed...

    Have you issued a "CLS" (Clear Screen) command to the Lcd - and then attempted to, "Paint a fresh screen."    Or - you may "Delay the Lcd's initialization somewhat" - in the event that the RTOS "house-keeping" might be intruding into the "full/complete" Lcd initialization process.

    As always - your "confirming this result" - upon a second Lcd - would make great sense & eliminate this as a "Single device anomaly."    (Dreaded by all diagnosticians...) 

  • 0 in reply to ToddMullanix
    Prodigy 220 points

    Hi Todd,

    Yes. The execution does get back to main() after reset.

  • 0 in reply to cb1_mobile
    Prodigy 220 points
    LCD Corruption - yes, the display on the LCD gets distorted when execution resumes after SysCtlReset()
    I have checked with a different LCD and the issue still exists.
    And yes, i have cleared the screen while initialization.

    Following LCD initializing steps are done before the BIOS_start()
    1. Reset cursor to home position
    2. delay of 10ms
    3. initialization of 16X2 LCD in 4bit mod
    4. Delay f 10ms
    5. Clear LCD
    6. Delay f 10ms
    7. Cursor off
    8. Delay f 10ms
    9. Entry mode
    10. Delay f 10ms
    11. Go to first line and 0th position
  • 0 in reply to cb1_mobile
    Prodigy 220 points
    Hi cb1_mobile,

    The issue has been resolved. I tried the "Paint a fresh screen." solution as you had mentioned. I wrote a blank screen onto the LCD after initialization before writing any characters onto the display. This resolved the issue of the LCD display getting distorted upon execution after SysCtlReset().

    Thank you all for the responses.
  • 0 in reply to Shyam Shankar
    Guru 117850 points

    Good for you my friend - proud of your "persistence" - and ability to accept guidance - from even humble "outsider."       Thank you for your "Verification" - and for your clear reporting...

    Now the "4-bit mode" of Lcd operation DOES appeal - primarily due to the "saving" of 4 GPIO.     Yet - that "GPIO Saving" - arrives  w/some cost!      Any "noise burst" or disturbance - which may  "glitch"  your Lcd's (sensitive) "E" signal line - can (and will) seriously disrupt your Lcd's operation.      (Exactly as you reported.)      

    Four-bit mode demands "perfect data sequencing" - and  "Double the number of Lcd "interactions" (than required by 8-bit mode) - and w/the "Added issue - imposed by the RTOS" - you  (may)  be entering w/in a high risk and/or "danger zone."

    I'd vote (early & often - "often" as I live in Chicago)  for your  "Switching to the "Eased & far more Robust" 8-bit data transfer mode!        8-bit transfer may (even) allow your Lcd to (better) coexist  w/vendor's RTOS...    (maybe!)       Bon chance, mon ami...

  • 0 in reply to cb1_mobile
    Prodigy 220 points
    Thank You. Shall try with the idea on moving forward. Thanks again.
  • 0 in reply to Shyam Shankar
    Guru 117850 points

    Good that - if I may advise - ALWAYS BEST to, "Choose Robustness" over,  "Few GPIO Saving!"      Really ... Always!