CCSV6 debug issue TM4C129ENCPDT

Further information:
After last unlock from LM Flash programmer the Blackhawk debugger ran for a while.
Until I executed the following code using the debugger step over

Watchdog_Params_init(&wdogParams);
wdogParams.callbackFxn = Watchdog_CallbackFn;
wdogParams.resetMode = Watchdog_RESET_ON;
watchdog = Watchdog_open(0, &wdogParams);

After calling watchdog_open the debugger reported errors

CORTEX_M4_0: Can't Run Target CPU: (Error -2134 @ 0x0) Unable to control device execution state. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 5.1.641.0)
CORTEX_M4_0: JTAG Communication Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 5.1.641.0)

Hello Barry,

It looks like the WatchDog function is expiring before the interrupt is getting serviced and generating a Reset. This reset is a System Reset and would cause the debugger to disconnect. What is the value of the Load Value in the WatchDog register being used and have you enabled STALL bit in the WatchDog?

Regards
Amit

Hello Amit

The problem was caused because I hadn't added Int_Priority to the HWattr for the watchdog.

As a result when the watchdog is enabled the interrupts priority was set to the load value of 0x80000000  and the load value would have defaulted to a value of 0.

It looks like this then locked the JTAG pins out as I needed to do a unlock port command through LM Flash Programmer to be able to debug again.

The debugging didn't just end, it was unable to be started again.

Once I added the Int_Priority and I unlocked the JTAG port all worked fine again.

Hello Barry

The load value is a true 32-bit value. So a load of 0x80000000 should not have reverted to 0x0. A simpler experiment would be to load 0x8000FFFF and in the interrupt handler for WDT toogle a GPIO when the interrupt is being cleared. If the toggle rate is 0x8000FFFF/System Clock then the load of bit 31 is correct. If not then we need to investigate

Regards
Amit

Hello Amit

The issue is not the load value it is the fact that if I left HWAttrs as before

const WatchdogTiva_HWAttrs watchdogTivaHWAttrs[A30307P26_WATCHDOGCOUNT] = {

/* EK_LM4F120XL_WATCHDOG0 with 1 sec period at default CPU clock freq */

{WATCHDOG0_BASE, INT_WATCHDOG, 80000000},

};

instead of

const WatchdogTiva_HWAttrs watchdogTivaHWAttrs[A30307P26_WATCHDOGCOUNT] = {

/* EK_LM4F120XL_WATCHDOG0 with 1 sec period at default CPU clock freq */

{WATCHDOG0_BASE, INT_WATCHDOG, (~0), 80000000},

};

I got no warnings of any errors but the resultant code when run locked up the debug port and effectively stopped the board from running unless I wend back to ICDI interface and used LM Flash programmer to unlock it..

When the intPriority field (~0) is added all works as it did previously. So my issue isn't that the watchdog doesn't work but rather that not adding the newly added field results in a silent but deadly crash to the code. I assume that when the intPriority is missing the code loads my load value as the intPriority and then defaults to some other value (possibly 0) for the load value.  When the intPriority is present the correct load value is used, the watchdog operates at the correct frequency and all is well.

Regards

Barry

Hello Barry,

Might you report this to RTOS Forum as at least a warning should be indicated if not an error.

Regards
Amit