TM4C1294NCPDT: TM4C1294 MCU is not reachable and likely core hung

Thank you - answers follow:    (cb1's initial suggestion;  cb1's follow-up response)

Senthil Paramasivam said:

Adding a regularly toggled Led to your TM4C (quickly) identifies any 'significant' loss of function. (tests MCU's: Timer, GPIO & Interrupt!)
<Senthil> It is good idea. We could validate the timer and GPIO access periodically and toggle the LED. How do you suggest to validate the interrupt?

That's easy - as the objective is the 'Evaluation of as many MCU System elements as (reasonably) possible' - simply have the (chosen) Timer's periodic 'Interrupt' call the 'X-Or'ed' GPIO.    Thus ... THREE BIRDS -  'SINGLE (cb1)  STONE.'    (Timer, GPIO & Interrupt all (regularly) tested & clearly monitored!)    Should the Led continue blinking - 'Hung Core' is (dismissed) as a realistic finding.

Senthil Paramasivam said:

Should you not have tried 'Resetting the TM4C's UART' - as well?
<Senthil> In our design we have to access TM4C's only from embedded CPU via UART interface. No direct access. In this case we couldn't access TM4C's from embedded board hence tried resetting UART on the embedded side.

It is unusual for the MCU's UART to 'just quit' - after performing properly from power-up.   Starting w/basics - have the signal levels (at the MCU) been recently measured - and confirmed as 'w/in spec?'   In many/most of our firm's designs - we program the UART(s) (via a Timer) to regularly  'Handshake (*) w/their attached device' (unless transaction activity is (both) high & recent!)   When a sufficient period of 'quiet' is detected - the MCU will 'Handshake' (*) - and await response.    Should that response fail to arrive - or appear (somehow) corrupted - then the MCU's UART will execute 'Peripheral Reset' - re-initialize - and attempt a new handshake.(*)    This involves the 'Addition of such 'broadening and robustness heightening' code strategy - w/in your design.   

Senthil Paramasivam said:

It proves 'advisable' - during development - to create 'active tests' - which 'monitor individual MCU peripherals' - and provide for 'Peripheral Recovery' - as/if/when needed...
<Senthil> Good idea, we will include them.

Good that!     Response (immediately above) notes (one method) to achieve such 'active test' - which 'Enables the MCU to 'detect issues' - and to 'Intelligently - attempt a fix.'    Note too - that each such 'Issue Detection'  may be programmed to produce a unique pattern upon the 'MCU monitoring Led' - announcing the issue - and 'Returning to normal' - when or should the 'fix' have succeeded!    In addition - it (always) proves wise - to 'Alert' the connected (Processor or Board) - that the MCU has 'Detected some issue' - is (about) to attempt a 'fix' - and then to signal the 'fix's' completion...

Senthil Paramasivam said:

And - what percent of your 'Total Field Population' do these 'inflicted boards' represent? That's important - is it not?
<Senthil> It is not important.    We don't have huge samples to conclude and observed this issue only on one of the customer setup multiple times.

May it be noted that MANY here would challenge your assessment of, 'NOT Important!'     Should the sample size be SO SMALL - then (any) failure proves 'GRAVE' - and the (thus far) 'limited discovery of such defects' - may reflect MORE upon your/client's 'Detection Techniques - and/or Effort' - than upon the 'Defects' (expanded) presence!     I believe that the adage,  'SAFE trumping Sorry' - (very) much applies - here...

Another notes 'Watchdog Usage' - which (can) cause a complete MCU Reset - and that (Reset) proves far more 'disruptive & time consuming' - than the 'specialized & focused - Peripheral-based techniques' - outlined herein.     And of course - W-Dog provides,  'NONE of the key INSIGHTS' - which the 'far more focused/effective' diagnostic methods presented herein - do so well...

(*) 'Handshake' - as noted here - does not involve 'flow control' or other (extra) signals.    Usage here describes a (very) brief, 'UART Exchange' - between the MCU & Remote - to insure that communication 'exists, is bi-directional - and is proper...'

Perhaps time (now) for a, 'This RESOLVED' green marker!    (note that the vendor has registered 'pleasure' w/such guidance.)

When you say 'Peripheral Reset', are you referring to embedded CPU (device) reset which is connected in UART or just resetting UART interface?

I deliberately employed 'Peripheral Reset' to distinguish the 'UART Peripheral's Reset.'     (such 'individual peripheral resets' are faster - and less disruptive - than an entire MCU Reset.)    In addition - they may be individually  'counted'  - thus providing insight into potential:  'program, component or system' issues!

I should note that our firm (usually) includes a small (external) EEProm (deliberately NOT that w/in the MCU) and this device is 'loaded' w/pertinent 'Diagnostic Info' which provides key data - even when the board is away (in client's possession.)

Freed from the (earlier) 'core-hung' (sense) - you now should be better prepared to produce a more robust design - and likely one which can 'Detect, (even) Overcome & then Record' (issues) - rather than ... run blind...

Like Like Like to include CB1 recent various colored text is very pleasing to read from. Besides the mission to Mars debug routines he suggest also very heavy in pull of earth gravity.

The debug for Tivaware console prints:

#define DEBUG              1   

//*****************************************************************************
//
// The error routine that is called if the driver library encounters an error.
//
//*****************************************************************************

#ifdef DEBUG
void
__error__(char *pcFilename, uint32_t ui32Line)
{
}
#endif


 UARTprintf("ASSERT_DEBUG: %s line:%d  %s\r\n", msg, __LINE__, __FILE__)

Watchdog example project can be found C:\ti\Tivaware\MyLibraryVerison\Examples. The NMI pin defaults PD7 must to be configured for Watchdog use (consult SYSCTRL registers text in datasheet), software simulated POR and can be triggered remotely from another device. It would seem certain exceptions might also somehow trigger NMI interrupt if configured to do so from Watchdog handling of NMI. That part is above my current pay grade, perhaps Charles/CB1 can chime in on how that might be accomplished.