Watchdog on LM4F232H5QD rev B0 not working when debugger not connected

Wonder if your testing is "far enough along" that WDG is your only issue? 

Our group has used Stellaris since their inception (along w/multiple other vendor ARMs) - never noted such an occurrence - > 25 unique designs...

Your code should properly set-up & config & then enable the WDG - I can't readily identify a JTAG sensitivity.   Your custom board should include pull-up Rs - each/every JTAG pin.  (we are not fans of "hoped for" internal MCU pull-ups for signals of such importance)  It may be that - if JTAG pins "float" - and these pins have not been configured away from their JTAG default - such strangeness arises.

Check also your Reset circuit - we find small C and pull-up R - located as close as possible to MCU - is best.

To test - I'd write test code which locks you in tight loop - and have WDG attempt to "escape."  Leds can confirm loop presence and escape...

We have put pull ups on our JTAG lines with no luck and we already had the pull up and small C on the reset line. I am currently only enabling a few GPIO for LEDs and have two loops ... the first blinks an LED for a few seconds and then makes a call to WatchdogResetEnable(WATCHDOG0_BASE); and then breaks from this loop. The program then enters a second loop which then toggles a second LED.

This works perfectly when I use the debugger to run the code (no stepping through ... just running flat out), but once I disconnect the debugger and try and run free it only makes it through the first loop and never enters the second.

Has your group had experience with the LM4F232H5QD rev B0 specifically? I don't see this problem on the rev A3 version of this same processor.

We were gifted w/very first LX4F BGA Eval bd. - and then several LX4F232 QFP's - can't recall Rev - but iirc the WDG was behaved.  We chose smaller 64 pin device due to size constraints - WDG performs nicely.  (even when JTAG out of the room/state/country...)

Only thing else may be debugger's "attachment" to Reset line - and possibly some "open ground" issue - corrected by your probe.  (have seen this @ clients...)  Have you carefully probed @ MCU Reset pin?  Our J-Link attaches to that pin - it may be that your pull-up R somehow fails to connect...  (a stretch - but w/in realm of possibility)

Believe there are 2 NMI pins - that MCU.  Insure that they're properly treated.  (datasheet lists & details) 

Dawns that your probe may also source 3V3 - and recall now client's VDD routing did not make it - to each/every such pin.  Attachment of JTAG probe masked or solved.  Suggests that your 3V3 regulator (or V Supply to your board) may also warrant testing.  Again - all of these have been "works only when probe attached" issues we've encountered - but I have zero recollection (or understanding) how this "targets" only the WDG.  (fear - too "vendor inside" or beyond this reporter's pay-grade...)

Turns out it was an initialization problem ... the example code with StellarisWare is spotty when it comes to initialization and the watchdog was something done very early on before finding out about the whole "you must call SysCtlPeripheralEnable(...) first" thing. It was just very confusing that it has worked for us for so long and just now started being a problem when we started working with the B0 processors.

Kyle Cottongim said:

On EK-LM4F232 eval board... I am able to load code which uses the watchdog ...and have everything work as expected.

So very hard to "balance" this - your initial report - with a failed WDG Initialization.

Should everything have worked as expected - minus a WDG Initialization?  (this reporter is doubtful...)