TM4C1297NCZAD: Can't be into the LCD interrupt

Aggil,

Thanks for your inquiry. I'll need to investigate the expected state of these registers and get back to you within a few days. In the meantime, can you please describe the fail state of your system further? What actions cause the system to enter a suspended state, and what exactly are the symptoms you experience in fail state?

Thanks.

Best Regards,
Philippe Dollo

Might these additional insights/questions - assist in this issue's resolution?

• Poster claims this to be a software issue - yet provides no support for that conclusion
• Further - he states that,  "Some prototypes" have this problem.    While that description is vague - it (may) suggest that  "Some prototypes WORK" - is that not true?
• And - if "some work" - "some fail" - and it is (assumed) that  the software is identical  (why would it change?)  then how can, "Software ALONE be blamed?"
• Does not the "failed" interrupt warrant more detailed description/identification?

Thus - is there not (both) insufficient detail & clarity - to render the data presently supplied - as, "Less than Actionable?"    (that's important - is it not?)

If we may assume that poster has employed a "factory provided" MCU board   AND  similar "factory provided" DLP Control Board (i.e. TWO separate boards - either cable or "plug-together" connected - then the method which follows - provides a "proven" path toward  MCU -> Display success.

Having worked w/many Displays - across multiple display technologies (yet not DLP) - firm/I have noted that the, "Simple Exchange of MCU boards" (i.e. from a working system to  non-working) serves to pin-point most issues as either: "MCU board or Controller board - caused."     Again - assumes that at least one early (or final) "Development System" employs (both) an: MCU Board and  cable connected/plug together - Display Controller Board.

The ease of "Swapping Boards" - greatly aids in the troubleshooting of such issues.      "Premature optimization" (placing the MCU and  DLP Display Controller in close proximity  (i.e. upon the same pcb) - voids the, "Eased/Speeded/Critical  GLEANING  -  of vital diagnostic discoveries/insights."     (this is so as there is no proper/eased means to, "SWAP MCU or Display Controllers - which enable the "highly valued" - ISOLATION of the issue!) 

Optimization proceeds best/safest - ONLY AFTER, "Everything has been well proven to work!"     Reducing Diagnostic Methods/Options - too soon -  "under the guise of  Optimization" - is unlikely to yield great success...