K61 watchdog

[lieven]

Hi,

We use an MK61FX512VMJ15 with 150MHz core clock with ucLinux and are having some difficulty with the watchdog.

It is set to 5 seconds (LPO clock source). Most of the time, it works perfectly, but sometimes the board resets when initializing the watchdog module (after reboot, RCM_SRS0 indicates WDOG and WDOG_RSTCNT is incremented).

The driver code:

static void kinetis_wdt_unlock(void)
{
volatile int tmrout;

KINETIS_WDOG->unlock = KINETIS_WDOG_UNLOCK_KEY1;
KINETIS_WDOG->unlock = KINETIS_WDOG_UNLOCK_KEY2;

tmrout = ((KINETIS_WDOG->tmrouth << 16) | KINETIS_WDOG->tmroutl);
}

static void kinetis_wdt_start(void)
{
unsigned long flags;

raw_local_irq_save(flags);
/* Unlock configure & control */
kinetis_wdt_unlock();
/* Configure & control, must be within WCT window (]1, 250] bus cycles) of unlock */
/* Clear INT */
KINETIS_WDOG->stctrll = (KINETIS_WDOG_STCTRLL_INTFLG_MASK
     | KINETIS_WDOG_STCTRLL_RESERVED_MSK);
/* Configure */
KINETIS_WDOG->winh = 0;
KINETIS_WDOG->winl = 0;
KINETIS_WDOG->tovalh = (u16)(heartbeat >> 16);
KINETIS_WDOG->tovall = (u16)(heartbeat & 0xffff);
KINETIS_WDOG->presc = 0;
/* No test mode, dedicated clk (LPO 1kHz) */
KINETIS_WDOG->stctrlh = KINETIS_WDOG_STCTRLH_WAITEN_MSK
    | KINETIS_WDOG_STCTRLH_STOPEN_MSK
    | KINETIS_WDOG_STCTRLH_ALLOWUPDATE_MSK  /* Still allow updates */
    | KINETIS_WDOG_STCTRLH_RESERVED_MSK  /* Always keep at default (1) */
    | KINETIS_WDOG_STCTRLH_WDOGEN_MSK;  /* Start */
raw_local_irq_restore(flags);
}

We use a test script in a loop that:

start WDOG

kick WDOG every second, 5 times

stop WDOG

wait 10seconds

The reset caused by WDOG always happens when starting it. The loop can run anywhere between a few to a few hundred times before triggering the WDOG reset.

Note that:

- init is protected against interrupts so that unlock sequence and init code is executed in 1 block within WCT window

- added in kinetis_wdt_unlock() a read of tmrout to make sure that status & control registers only are accessed after at least 1 bus clock cycle after unlock as stated in K61 manual p612.

Can you see any reason why it still resets sometimes on init?

Best regards

[lieven]

Thanks Jorge.

I am aware of all the many restrictions and suspect that's where the problem is.

Our board is booted with U-Boot and one of the first tasks is to disable WDOG, but still allow updates. U-Boot launches Linux with our WDOG driver, still disabled (takes about 10sec). At this point, we never have a problem.

The WDOG will be used by our main Linux app: it starts WDOG (LPO source 5sec timeout, every sec refresh), but when the app is restarted, it needs to disable WDOG when exiting and restart it also. This is were the problem occurs, therefore the test as mentioned previously. Refresh never is a problem only starting (and very rarely) stopping WDOG.

I read another thread Hi All , I have been trying to implement Watchdog in MK70FN1M0VMJ12 (the controller in K70 tower ...

and remarked that just after the unlock and before the write of any control register there was a function watchdog_delay(1) to assure at least 1 bus cycle between unlock & configure (there is no explanation why the author has added it, while no other code I have seen adds code between unlock & configure). So I replaced my read of tmrout after unlock with this function. It did change the frequency of my reset problem from about 1 in 100 to 1 in 300. So improvement. As this thread was for a K70 @120MHz and our board is @150MHz, I doubled the count and the problem now occurs about 1 in 800.

In view of this result, I have following questions:

- the required bus cycle: is it really the core bus cycle (so 75MHz), or is it an LPO cycle (1ms) ?

- how to guarantee 1 bus cycle in a instruction cached system (preferably core clock independent)

Regards

Lieven

[Jorge_Gonzalez · Accepted solution]

Hello Lieven:

That behavior is then very strange. Could it be that your tmrout read was optimized somehow?

Responding to your questions:

1) Yes, it is the bus cycle. 75 MHz only if the bus is configured that way (with MCG and SIM clock divider).

2) If bus clock is half the core clock then executing any 2 instructions would guarantee 1 bus cycle delay.

Regards!

Jorge Gonzalez

[lieven]

Thanks again Jorge.

The core & system clock are indeed configured @150MHz (=OSC0ERCLK*PLL_VDIV/PLL_PRDIV/2 where OSC0ERCLK=50MHz, PLL_VDIV=24, PLL_PRDIV=4), and bus clock @75MHz (PCLK_DIV=2).

The original code did two 16 bit register reads (tmroutl & tmrouth). It does not seem to work always though. I replaced it with Navinar's function (see other thread):

void watchdog_delay(uint16_t nCount)

{

    uint16_t delay = 0;

    for (delay=0;delay<nCount*10;delay++)

    {

        NULL;

    }

    return;

}

with 2 as parameter (so a count of 20), I still get a problem in about 1 in 800 WDOG restarts. With param 1 (count = 10) it is about 1 in 300. So I know that the function is not optimized away.

I am sure it still is WDOG that reboots the board (RCM_SRS0 still indicates WDOG and WDOG_RSTCNT is incremented). But I will have to investigate further, as I now saw a Linux panic (causing a reboot after 10sec timeout), so when WDOG set to 5sec, this is totally normal.

[Jorge_Gonzalez]

Hello Lieven Schiltz:

How soon after system reset are you configuring the watchdog?

The unlock sequence must happen within 256 bus clock cycles after system reset (Power On, Reset_b pin). So unlocking and configuring the watchdog should be made before any time consuming operation (e.g. copying data from Flash to RAM).

As you can see from the Reference Manual, there are just a few reasons for the Watchdog to generate a reset:

Regards!

Jorge Gonzalez