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.

Possible hardware fault with watchdog TM4C129ENCPDT

Other Parts Discussed in Thread: TM4C129ENCPDT, LMFLASHPROGRAMMER

I am using the watchdog timer on TM4C129ENCPDT processor.

I have now had two occasions where after I did a test of the watchdog (Just wait till it reset the processor) the processor doesn't reset.

Not only that but it ignores the reset pin on start up as well.

I can get the processor to run again using CCSV6 to reload a program and run it through the JTAG.

However once I power the board down it will not power up again of its own accord, I once again have to use the JTAG interface to get the processor to run.

It is as though the execution of the watchdog interrupt has disabled something internal which causes reset to no longer work.

Here is my code to create the watchdog in the first place and also the callback function.

In order to test the watchdog all I do is set my ResetActivated flag and then wait for 10 seconds.

The watchdog should hit after 1 second, if it doesn't I will report an error after the 10 seconds and clear the flag.

This routine never exits, the processor just seems to shutdown and I cannot get it to run again without using the JTAG.

I am certain I have had this working without issue on previous TM4C129ENCPDT devices but these latest ones both failed the same way! 

// Create and enable a Watchdog with resets enabled

Watchdog_Params_init(&wdogParams);

wdogParams.callbackFxn = Watchdog_CallbackFn;

wdogParams.resetMode = Watchdog_RESET_ON;

watchdog = Watchdog_open(0, &wdogParams);

if (watchdog == NULL)

{

System_abort("Error opening Watchdog!\n");

}

// ===========================================================

// ======== Watchdog_CallbackFn ========

// Watchdog interrupt callback function.

// It clears the watchdog interrupt flag.

// ===========================================================

Void Watchdog_CallbackFn(UArg handle)

{

if (!ResetActivated)

Watchdog_clear((Watchdog_Handle)handle); // hit the watchdog if we don't want reset

}

This is all running under tirtos_tivac_2_14_00_10

  • Found the cause of the lockup and the solution.

    If I do the watchdog test whilst my redprobe interface is connected via CCSV6 then the processor locks up.
    This is the case if I have watchdog debugStallMode set to ON or OFF

    In order to recover the processor I used my ICDI debug interface with LMFlashProgrammer and reprogrammed my boot loader.
    This then allows reset to operate normally again.
    If you do the watchdog test without the redprobe being connected, all works fine and the board restarts as expected.

    It seems the watchdog firing off while the Red Probe JTAG is connected causes some sort of debug mode to be enabled within the processor.

    Once this debug mode is enabled the reset circuitry does not work correctly and even powering the board down overnight won't recover it.

    I found the debug mode (for want of a better term) is not automatically disabled by using the redtag to program the processor through CCSV6. However it is returned to normal operation when you use the ICDI interface and LMFlash programmer. In my case I am using the mikroprog ICDI module (Simply because it is cheap and a nice package to handle for our production people).

    Hopefully this information helps someone else who comes across this issue.
  • Hello Barry,

    There is a setting in Debug configuration called "Halt CPU on Reset". That is what may be causing the Lock Up.

    Regards
    Amit
  • Hello Amit

    Thanks for the response.

    I have looked at debugger options and cannot find a "Halt CPU on Reset" option
    Checked the debug configuration target settings under all options.
    There is a "halt at program termination" option, unchecking this did not fix the issue.

    With regards the watchdog itself

    I tried setting Watchdog_DebugMode to Watchdog_DEBUG_STALL_ON (Default) and Watchdog_DEBUG_STALL_OFF
    It didn't matter which way I set this.
    As long as the watchdog hit while the redprobe was connected I got the lockout of the reset functionality.

    Watchdog_ResetMode is set to Watchdog_RESET_ON so should cause a reset and not just an interrupt.

    Regards
    Barry
  • Hello Amit

    I found the problem.
    I am using a bootloader at lower memory address and then an application loaded at higher address.
    The new project I was working on had "erase entire flash before load" set, so when I used the watchdog within the debug environment, my bootloader had been erased by the CCSV6 load and hence there was no reset vector where the processor expects it.

    Reprogramming the bootloader obviously fixed this.

    Bit of a trap for debugging apps which don't load at the default vectors.
  • Hello Barry,

    Or setting the option to "Erase only required Sector"

    Regards
    Amit