WDT prevents XDS100v2 connecting

Hi Sai,

I have not been able to recover the board.

Ultimately, I tried the LM FLASH Programmer Debug Port Unlock without success.  It puts a warning message box about losing stored value and I clicked OK.  Next it puts up a message box that says "Assert and hold reset while powering up the device."  I have done so, but I always get "**ERROR** Failed to unlock connected device!"  I have tried clicking OK on the "Assert..."box both before and after releasing reset.

I have LM Flash Programmer build 1613.  I have tried the following configuration tab settings with Speed (Hz) = 1000000, Using selected crystal value 25 MHz (matches the target board):  {Tried with Other Utitilites | Debug Port Unlock | radio buttions set in both positions}

Quick Set = Manual Configuration, Interface ICD1, port JTAG

Quick Set = Manual Configuration, interface ICD1, port SWD

Quick Set = Manual Configuration, Interface Red Probe, port JTAG

Quick Set = Manual Configuration, interface Red Probe, port SWD

Quick Set = TM4C1294XL LaunchPad

None of these have worked.

What should all these LM Flash Programmer settings be?  What else can we try?

Tom

Tom Farmer said:

What should all these LM Flash Programmer settings be?  What else can we try?

Instead, there is a command line option in CCS to perform a device unlock using a XDS100v2 - see https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/475655#1714727

Tom Farmer said:

What else can we try?

Hi Sai,

The board is not a launchpad; it is a proprietary board.  The emulator worked fine with the board until I managed to install firmware that causes the watchdog to trip early in the boot-up process.  I do not have a launchpad board.

As for drivers, none of the Stellaris drivers appear.  All that appears are under Universal Serial Bus Controllers -- TI XDS100 Channel A and TI XDS100 Channel B.

Tom

More likely - a (potential) solution has been provided. (as poster Chester noted)
Enabling the watchdog so early w/in main is very risky practice! (just as is (early) JTAG switch-over to GPIO)

Poster did not justify that (early) action - and (now) pays the price.

Amit Ashara said:

Chester has already provided the solution.

Here's where our communication breaks down:

• Chester (I believe properly) noted that there was (some) chance that his "Gel Script" method may not achieve "Command/Control" w/the offensive code placed so early w/in the code bank.
• Your quote (above) appears to "over-ride" Chester's caution.
• I noted that conflict - sought clarification

Too short answers - even from a master - rarely, fully/properly succeed.   (or prove convincing)

Phrased differently (for uber clarity) is it your belief that a "Gel Script" will ALWAYS enable errant (suspect) code to be halted - (even) when such code is "immediately" executed?   AND (especially when such code is "immediately" executed!)

I've "no dog" in this fight - simply believe a correctly detailed answer will prove useful to thread originator & many (others)...

cb1_mobile said:

Here's where our communication breaks down:

1) Use a CCS command line tool to perform a device unlock using the XDS100v2 emulator. This has the advantage that a device unlock is requested by JTAG-to-SWD and SWD-to-JTAG switch sequences while holding the microcontroller in reset, meaning it occurs while the software is not running. The disadvantage is that all non-volatile information is erased (e.g. erases the MAC address non-volatile registers)

2) Use a GEL script to attempt to disable the watchdog while attaching the debugger. The disadvantage is that the GEL script may not be able to disable the watchdog in time to allow the debugger to attach. The advantage is that won't erase the non-volatile registers and EEPROM.

Indeed you did make two suggestions. Note that they appeared (separately - w/in different postings) and such is never as effective as a complete listing - w/in one single (summarizing) post.

Might it be that you missed the fact that my request for "clarification" was aimed at Amit?    His assertion of a "solution" (provided by you) flew (somewhat) in the face of your (still proper) uncertainty that the Gel script could, "seize control."  

And - as you've provided two suggestions - is it not fair/proper to ask Amit (which solution/suggestion) is the one he believes and/or favors?   

Hi Amit,

Thank you - appreciated - your (more detailed) writing now proves (far) more understandable.

That said - "Unlock" is brutal - and causes the loss of pre-programmed data - placing "added load" upon users.

Poster Chester's (second) idea (GEL script) - if it (could) succeed - seemed inspired and places less "wear/tear" upon hapless user...

As an added point to the (always) dreaded, "Cannot Connect" - would not (near) universal use of past program, "GPIO-JTAG.c" placed atop all (other) program code - provide a "SAFETY/DEFENSE MECHANISM" - insuring that users can (most always) HALT their MCU?   (firm/I do just that - and along w/IAR & J-Link - we've NOT been "Connect Challenged" for past 2+ years...)

Hi Amit,

And - let it be (equally) noted - poster's first few postings make "No mention" of Bootloader nor BOOTCFG. If that appears (somewhere) in this long, back-forth mix - I've missed it.

Further - for those Apps NOT using bootloader - does not forgotten/discounted, "GPIO-JTAG.c" rise to, "Head of the (always) connected class?"

Thanks to all who suggested fixes but I was not able to recover the board.  Rather than spend more time with this, we decided to have our CM replace the chip.

As for the question about why we got into this mode, there were two reasons.  One was that there was a recommendation somewhere in the TI documentation to invoke the watchdog as soon as possible. 

The second reason was that our board is used in an industrial application and is subject to severe EMC.  We had problems with our original Stellaris-version hanging when exposed to ESD and radiated-immunity testing.  With this new TIVA-version, we are starting a lot of tasks and we were concerned that a single task might hang (due to EMC effects) while the rest of the tasks continued to run fine.  This has a high risk of happening in radiated-immunity testing because the stimulus that caused a watchdog reset might still be being applied as the board returned from the watchdog-initiated reset.

Note that I made the wrong assumption that the XDS100v2 emulator worked like various in-circuit emulators I have used in the past with other chips.  These emulators power up with complete control of the device and can even be used to hardware debugging.  Unfortunately, the XDS100v2 seems to have much less capability but it also is dramatically lower in cost.  (Other than this reset issue, the XDS100v2 has met all of my other needs; this is not a complaint about the XDS100v2.)

For completeness -- each of our tasks has a flag that it sets every time the task is executed.  Our "idle" tasks waits until all the flags are set.  Once that happens it reloads the watchdog down counter and clears all of the task flags.  There is an arbitration mechanism in place to avoid write conflicts.  End result is that the watchdog will eventually timeout if any of the tasks fails to set its flag.

Hi Amit,

I was not able to get that to work.  Coming out of reset, the WDT would fire before the emulator seemed to connect to the target.

Tom

I tried exactly that, but the emulator would not communicate with LM Flash Programmer nor with CCS.   I don't remember what the error messages were.   The impression I got was that the board-level reset signal was also resetting the emulator, but I did not tear the emulator apart to verify this...

I am not able to try anything further because the board is currently being reworked at the CM (TIVA chip replacement).

Tom