CC3200 Watchdog doesn't work as expected

Hi,

I am not sure if this can be related to your topic, but check www.ti.com/.../getliterature.tsp chapter 10.4.

Jan

Thanks Jan for your reply.

I've read this section of TRM. It seems to be doesn't connected with my issue.

I understand that I have to check the recovery reason after the reset, and if reset was caused by WatchDog I have to trigger the hibernation cycle to make gracefully clean reset.

But in my case the MCU is NOT reset by WatchDog at all.

BTW: I implemented this mechanism in my code, but the result is still the same (no reset from WatchDog)

I don't know if it can be any clue, but if faultHandler occurs (MCU in lockup state) - reset by WatchDog works.

Mike

Hi,

Please share minimal code to demonstrate issue (use code highlighter in rich editor). I will try quickly look on it.

Jan

Hi,

I am working on quite huge project, using FreeRTOS, so it's really hard to extract just a working code snippets with WatchDog.  Please find below some functions of WatchDog routines:

#define MILLISECONDS_TO_TICKS(ms)		((configCPU_CLOCK_HZ / 1000) * (ms))

static void WatchdogIntHandler(void)
{
    puts("Reset caused by WatchDog\n");
    return;
}

static void ti_wdt_init(uint32_t timeout_ms)
{
	MAP_PRCMPeripheralClkEnable(PRCM_WDT, PRCM_RUN_MODE_CLK);
	MAP_WatchdogUnlock(WDT_BASE);
	// Interrupt configuration:
	// Use the highest available priority to be able to reset device by
	// WDT also in MCU panic:
	MAP_IntPrioritySet(INT_WDT, INT_PRIORITY_LVL_0);
	MAP_WatchdogIntRegister(WDT_BASE, WatchdogIntHandler);

	MAP_WatchdogReloadSet(WDT_BASE, MILLISECONDS_TO_TICKS(timeout_ms));
	MAP_WatchdogEnable(WDT_BASE);
}

static void ti_wdt_feed(void)
{
	// Acknowledge WDT by clearing interrupt:
	WatchdogIntClear(WDT_BASE);
}

static int ti_system_init(void)
{
	uint32_t reset_cause = PRCMSysResetCauseGet();

	if (reset_cause == PRCM_WDT_RESET) {
		ti_trigger_hib_cycle();
	}

	ti_wdt_init(10000);
.
.
.
}

I know that it's hard to debug this issue basing on just these snippets, but maybe WatchDog initialization procedure is a reason of this issue.

Hi,

You are using FreeRTOS. That is new information. I think this issue can be related to FreeRTOS. How FreeRTOS acts when interrupt flag is not cleared? I don't know because I use TIRTOS. But it can be maybe clue.

Exactly same question was here few days before (but without answer) see: e2e.ti.com/.../548599

During few days I can look on it at my platform (TIRTOS), unfortunately I haven't time to to try this at FreeRTOS. But I hope that someone for TI will be able help you.

Jan

Thanks Jan,
I've tried TI an example provided with SDK (name: watchdog) and it seems to be OK - but this demo has not contain FreeRTOS implementation.
I think you may have right - this could be connected with FreeRTOS implementation.
At the beginning I suspected the priority of timer for scheduler (SysTick), which could "expropriated" interrupt from WatchDog. But I've check it and the priority of SysTick was lower than for WatchDog module.
I have to take a deeper look at my FreeRTOS port.

Thanks for hint.

Mike

Hi, did you found a solution or the cause to this issue. I'm facing same problem and I'm also using FreeRTOS.

Any help would be appreciated.

Thanks,
Sérgio

Hi Sérgio,

Unfortunately I didn't find a solution of this problem.

As a workaround you can try trigger hibernate cycle in WDT interrupt handler and store the information of reset in OCR register, to perform clean reset further (after boot up).

NOTE from TRM: The MCU application must detect a recovery from the WDOG trigger and force the device into complete hibernation with wake-up associated with an internal RTC timer. This ensures a complete system cleanup.

Good luck

Mike

Hi Mike,

Thank you for your reply.

I was already using a similar workaround where I simply use WDT interrupt to complete hibernate. For now it is working for me, but it is still a "workaround"!

Hope someone at TI is working on this...

Regards,
Sérgio