Watchdog enable

[Renan]

Hi Mark,

I am not able to use the Watchdog to restart my processor, created a infinite loop "while (1)" and it appears that the watchdog was not triggered because my plate not restarted.
The configurations were made as shown in the tutorial for Coldfire M5223X.

    INIT_WATCHDOG_LED ();
     INIT_WATCHDOG_DISABLE ();
     If (! WATCHDOG_DISABLE ()) (
         CWCR = CONFIGURE_WATCHDOG;
     )
     Else (
         CWCR = WATCHDOG_DISABLED;
     )

I think I am setting up something wrong.
I would also like to know how I can create delays simple without using the timers, it is possible?

Regards...

Renan André Canello

[mark]

Hi Renan

If the watchdog is enabled it should cause a reset on the hardware.

1. Check that the watchdog is really being enabled by stepping through the configuration code. It must do
CWCR = CONFIGURE_WATCHDOG;

which, when expanded, is

Code: [Select]

        CWCR = (CWE | WATCHDOG_2_SEC | CWTA | CWTAVA | CWTIF);
        fnSetIntHandler(SW_WD_VECTOR, (unsigned char *)_sw_wdog_timeout);
        IC_ICR_0_8 = (INTERRUPT_LEVEL_7 | INTERRUPT_PRIORITY_7);
        IC_IMRL_0 &= ~(SW_WDG_PIF_INT_L | MASK_ALL_INT);
By connecting a certain input (defined in WATCHDOG_DISABLE()) to ground, the watchdog can be disabled. When debugging it is practical to disable the watchdog.

2. Note that the watchdog in the M5223X is not fool-proof. It relies on an interrupt to actually perform the reset. If for some reason the interrupt doesn't work it will also not reset.

Where are you putting the while(1) {} ?
Is it before the watchdog has been set up?
Is it possible that it is before main interriupts have been activated (although I would expect the NMI to always work)

3. Check that the interrupt (_sw_wdog_timeout()) is arriving, this will perform the reset by using the command:
RESET_RCR = SOFT_RST;



Simple delays can of course be created using loops - the following generates approx. 25ms delay.

volatile unsigned long ulDelay = ((BUS_CLOCK/12000) * 25);

    if (iChipSelect == 0) {
        while (ulDelay--) {};                                            // start up delay to ensure SPI FLASH ready {17}
    }

However timers are of course much more practical sincne several can operate in parallel and teh code doesn't have to wait in the loop before it can do something else.

Regards

Mark

[Renan]

Hi MArk,

1.I checked my code and it enables the Watchdog always through
CWCR = CONFIGURE_WATCHDOG;

Watchdog activation defines is ...

Code: [Select]

#define ACTIVE_WATCHDOG_2_SEC   (CWE | WATCHDOG_2_SEC | CWTA | CWTAVA | CWTIF);
fnSetIntHandler(SW_WD_VECTOR, (unsigned char *)sw_wdog_timeout);
IC_ICR_0_8 = (INTERRUPT_LEVEL_7 | INTERRUPT_PRIORITY_7);
IC_IMRL_0 &= ~(SW_WDG_PIF_INT_L | MASK_ALL_INT);

2. I am putting the "while (1)" at the end of the application task "fnApplication" and I think now the main interrupts have already been started.

3. My interruption _sw_wdog_timeout () is using the command RESET_RCR = SOFT_RST to restart.

Everything seems to be as it should be, but the watchdog is never restart...
It would have a different configuration or test that I could do?

Regards..
   
Renan   

[mark]

Hi Renan

The main interrups are activated before the tasks are started so your test is good.
At the moment I can't understand why the watchdog would not trigger since it seems to be set up correctly.
Have you put a break point in the watchdog interrupt to see whether it ever arrives?
You could also stop the board running after some time in teh llop and look at the watchdog registers and interrupt flags to see whether you can get an idea.

As far as I am aware the watchdog is operating correctly in the project (as it it delivered). I know that if you try to debug without disabling the watchdog there are difficulties due to it firing. Also we did tests with some large external SPI FLASH which required about 5s to completely be deleted and this cause the watchdog to fire when left at the initial 2s timeout (at 60MHz PLL speed).

I will repeat your test on Saturday in case you haven't discovered anything by then. Unfortunately I will be aways until then (also without Internet connection...) so can't do this test just now.

Good luck

regards

Mark

[mark]

Hi Renan

I have added the following to the M5223X project V1.3 + SP5 and tested in the M52235EVB.

...
    while (1) {}  // forever loop in application.c before the read of the input queue

    while ( fnRead( PortIDInternal, ucInputMessage, HEADER_LENGTH )) {   // check input queue
...

If I load the code and power up the board with watchdog disabled (IRQ4 connected to 0V to disable watchdog activation) the board 'hangs' - without Ethernet connection I have the SPD LED lit and also the LEDs 1..4. After 6 seconds LED3 is turned off since the RTC test is operating in my version and these interrupts are still operating. Some time later LEDs lights again and LED4 is turned off. After about 1.5 minutes LED3 blinks at 1s interval. If you don't have the RTC test enabled in application.c all LEDs will probably remain on all the time. This means that the forever loop is being executed but interrupts are still enabled. The board remains in this state forever.

If I disconnect the IRQ4 input from 0V so that a 2s watchdog timer out is enabled (at 60MHz operation) and power up again I get a reset of the board every approx. 2s. I see thsi beacsue the SPD LED is blinking and the LED1 is also being turned off for a short time at this rate.

This test shows that the watchdog is operating as expected using the standard demo project with the additiom of the forever loop in application.c.

At the moment I don't understand why you can't reproduce the same result.
Can you think of an explanation due to the use of a different board or different version of the chip?

Regards

Mark

[Renan]

Hi Mark,

I used the original version and could reproduce the same result. Then I returned some earlier versions and also worked, I have changed something that impair the functioning of the watch dog, but now is functioning properly.

Thanks,
Renan.