[U-Boot] Coldfire: MCF5271: Periodic HW watchdog petting and sleep function does not work.

[U-Boot] Coldfire: MCF5271: Periodic HW watchdog petting and sleep function does not work.

[Richard Retanubun]

Hi Guys,

I am using u-boot 2009.03-rc1 and a board based on Coldfire MC5271EVB eval platform.
Our external watchdog is a MAX6369.

I have #define CONFIG_HW_WATCHDOG and #undef CONFIG_WATCHDOG in our board's config file and
have created the hw_watchdog_reset function to toggle the WDI line to pet the watchdog.

However, my board keeps resetting at the watchdog timeout. Upon probing, I found out that
the watchdog toggle line in not being toggled periodically by u-boot. Which means a regular call
to WATCHDOG_RESET() is not happening. If I execute commands, the WDI will get toggled and the watchdog
will not timeout, which means that the WATCHDOG_RESET() mapping to hw_watchdog_reset function is working, it is
just not being called periodically.

I am looking at the programmable interrupt timer that the get_timer() function uses, and so far everything checks out.

I'm also stuck at using u-boot's sleep command, e.g. "sleep 1" will never return. Which I suspect may be the same root cause.
(this can also be observed on the M5271EVB board).

What am I missing here?

Thank you for all your time.

Regards,

- Richard Retanubun.

[U-Boot] Coldfire: MCF5271: Periodic HW watchdog petting and sleep function does not work.

[TC Liew]

Richard,

Can you be more specific on how the MAX6369 WDO and WDI connects to
MCF5271's signal? Is it GPIO? ResetIn? Others?

Regards,
TsiChung

On Mon, Mar 2, 2009 at 3:05 PM, Richard Retanubun <
RichardRetanubun@ruggedcom.com> wrote:

> Hi Guys,
>
> I am using u-boot 2009.03-rc1 and a board based on Coldfire MC5271EVB eval
> platform.
> Our external watchdog is a MAX6369.
>
> I have #define CONFIG_HW_WATCHDOG and #undef CONFIG_WATCHDOG in our board's
> config file and
> have created the hw_watchdog_reset function to toggle the WDI line to pet
> the watchdog.
>
> However, my board keeps resetting at the watchdog timeout. Upon probing, I
> found out that
> the watchdog toggle line in not being toggled periodically by u-boot. Which
> means a regular call
> to WATCHDOG_RESET() is not happening. If I execute commands, the WDI will
> get toggled and the watchdog
> will not timeout, which means that the WATCHDOG_RESET() mapping to
> hw_watchdog_reset function is working, it is
> just not being called periodically.
>
> I am looking at the programmable interrupt timer that the get_timer()
> function uses, and so far everything checks out.
>
> I'm also stuck at using u-boot's sleep command, e.g. "sleep 1" will never
> return. Which I suspect may be the same root cause.
> (this can also be observed on the M5271EVB board).
>
> What am I missing here?
>
> Thank you for all your time.
>
> Regards,
>
> - Richard Retanubun.
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

[U-Boot] Coldfire: MCF5271: Periodic HW watchdog petting and sleep function does not work.

[Richard Retanubun]

TC Liew wrote:
> Richard,
>  
> Can you be more specific on how the MAX6369 WDO and WDI connects to 
> MCF5271's signal? Is it GPIO? ResetIn? Others?
>  
> Regards,
> TsiChung

Hi TC,

Thanks for responding,

WDI is connected to a CPU GPIO, PTIMER[3] on our board and WDO is connected to the active low RESETIn of the CPU.

In case it matters, my hw_watchdog_reset function looks like this:

/*
  * In <watchdog.h> this function is MACRO-ed to WATCHDOG_RESET
  * The watchdog control pins are as follows:
  * WDI         = PTIMER[3] (DT1IN)
  * WD_SET[2:0] = PTIMER[2:0] (DT1OUT, DT1IN, DT0OUT)
  */
void hw_watchdog_reset(void)
{
	/* Setup the value first, then make it a GPO to avoid glitches */

	/* Any edge is ok to reset watchdog (Bit is XORed each time) */
	mbar_writeByte(MCF_GPIO_PODR_TIMER,
		       (mbar_readByte(MCF_GPIO_PODR_TIMER) ^ 0x08));

	/*
	 * While it is true that seting the WDI as a GPO is only needed once,
	 * it is so critical for operation, hence it is enforced each time.
	 */

	/* Setup WDI direction as an output */
	mbar_writeByte(MCF_GPIO_PDDR_TIMER,
		       (mbar_readByte(MCF_GPIO_PDDR_TIMER) | 0x08));

	/* Set the pins as GPIO */
	mbar_writeShort(MCF_GPIO_PAR_TIMER,
			(mbar_readShort(MCF_GPIO_PAR_TIMER) & 0xF3FF));
}

Thanks for your time.

- Richard Retanubun
> 
> On Mon, Mar 2, 2009 at 3:05 PM, Richard Retanubun 
> <RichardRetanubun at ruggedcom.com <mailto:RichardRetanubun@ruggedcom.com>> 
> wrote:
> 
>     Hi Guys,
> 
>     I am using u-boot 2009.03-rc1 and a board based on Coldfire
>     MC5271EVB eval platform.
>     Our external watchdog is a MAX6369.
> 
>     I have #define CONFIG_HW_WATCHDOG and #undef CONFIG_WATCHDOG in our
>     board's config file and
>     have created the hw_watchdog_reset function to toggle the WDI line
>     to pet the watchdog.
> 
>     However, my board keeps resetting at the watchdog timeout. Upon
>     probing, I found out that
>     the watchdog toggle line in not being toggled periodically by
>     u-boot. Which means a regular call
>     to WATCHDOG_RESET() is not happening. If I execute commands, the WDI
>     will get toggled and the watchdog
>     will not timeout, which means that the WATCHDOG_RESET() mapping to
>     hw_watchdog_reset function is working, it is
>     just not being called periodically.
> 
>     I am looking at the programmable interrupt timer that the
>     get_timer() function uses, and so far everything checks out.
> 
>     I'm also stuck at using u-boot's sleep command, e.g. "sleep 1" will
>     never return. Which I suspect may be the same root cause.
>     (this can also be observed on the M5271EVB board).
> 
>     What am I missing here?
> 
>     Thank you for all your time.
> 
>     Regards,
> 
>     - Richard Retanubun.
> 
> 
>     _______________________________________________
>     U-Boot mailing list
>     U-Boot at lists.denx.de <mailto:U-Boot@lists.denx.de>
>     http://lists.denx.de/mailman/listinfo/u-boot
> 
> 

[U-Boot] Coldfire: MCF5271: Periodic HW watchdog petting and sleep function does not work.

[Richard Retanubun]

Richard Retanubun wrote:
> Hi TC,
> 
> TC Liew wrote:
>> Richard,
>>  
>> Is there a purpose that you used DTIMER 3 but not 1 or 2? FYI: DTIMER3 
>> is currently used for system time, DTIMER0 is currently used for 
>> udelay() in u-boot.
>>  
>> You can change the u-boot 5271's system timer in 
>> include/asm-m68k/immap.h.
>> #define CONFIG_SYS_TMR_BASE       (MMAP_DTMR1)
>> #define CONFIG_SYS_TMRINTR_NO    (INT0_LO_DTMR1)
>> #define CONFIG_SYS_TMRINTR_MASK (INTC_IPRL_INT20)
>>  
>> Regards,
>> TsiChung
> 
Hi TC,

Sorry for the long-delay on this issue, I got tasked with other stuff,
but thanks to your hint from the last e-mail,
I think I might have found the root-cause to the problem.

In include/asm-m68k/immap.h.

#ifdef CONFIG_M5271
#include <asm/immap_5271.h>
#include <asm/m5271.h>

#define CONFIG_SYS_FEC0_IOBASE		(MMAP_FEC)
#define CONFIG_SYS_UART_BASE		(MMAP_UART0 + (CONFIG_SYS_UART_PORT * 0x40))

/* Timer */
#ifdef CONFIG_MCFTMR
#define CONFIG_SYS_UDELAY_BASE		(MMAP_DTMR0)
#define CONFIG_SYS_TMR_BASE		(MMAP_DTMR3)
#define CONFIG_SYS_TMRPND_REG		(((volatile int0_t *)(CONFIG_SYS_INTR_BASE))->iprl0)
#define CONFIG_SYS_TMRINTR_NO		(INT0_LO_DTMR3)
#define CONFIG_SYS_TMRINTR_MASK	(INTC_IPRL_INT22)
#define CONFIG_SYS_TMRINTR_PEND	(CONFIG_SYS_TMRINTR_MASK)

#define CONFIG_SYS_TMRINTR_PRI		(0)		/* Level must include inorder to work */
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#define CONFIG_SYS_TIMER_PRESCALER	(((gd->bus_clk / 1000000) - 1) << 8)
#endif

According to MCF5271 RefMan Rev 2 (07/2006) page 13-12,
I think this means that the interrupt, although unmasked, have a level 0, priority 0,
which essentially disables it.

What should be the proper value? (0x09) will make it level 1, priority 1, is this ok?
Or am I chasing the wrong rabbit?

Thanks for your time

- Richard

[U-Boot] Coldfire: MCF5271: Periodic HW watchdog petting and sleep function does not work.

[TC Liew]

Richard,

I used 6 for most platforms. 1 is lowest priority - 7 - is the highest.

Regards,
TsiChung

On Thu, Mar 19, 2009 at 4:15 PM, Richard Retanubun
<RichardRetanubun@ruggedcom.com> wrote:
> Richard Retanubun wrote:
>>
>> Hi TC,
>>
>> TC Liew wrote:
>>>
>>> Richard,
>>> ?Is there a purpose that you used DTIMER 3 but not 1 or 2? FYI: DTIMER3
>>> is currently used for system time, DTIMER0 is currently used for udelay() in
>>> u-boot.
>>> ?You can change the u-boot 5271's system timer in
>>> include/asm-m68k/immap.h.
>>> #define CONFIG_SYS_TMR_BASE ? ? ? (MMAP_DTMR1)
>>> #define CONFIG_SYS_TMRINTR_NO ? ?(INT0_LO_DTMR1)
>>> #define CONFIG_SYS_TMRINTR_MASK (INTC_IPRL_INT20)
>>> ?Regards,
>>> TsiChung
>>
> Hi TC,
>
> Sorry for the long-delay on this issue, I got tasked with other stuff,
> but thanks to your hint from the last e-mail,
> I think I might have found the root-cause to the problem.
>
> In include/asm-m68k/immap.h.
>
> #ifdef CONFIG_M5271
> #include <asm/immap_5271.h>
> #include <asm/m5271.h>
>
> #define CONFIG_SYS_FEC0_IOBASE ? ? ? ? ?(MMAP_FEC)
> #define CONFIG_SYS_UART_BASE ? ? ? ? ? ?(MMAP_UART0 + (CONFIG_SYS_UART_PORT
> * 0x40))
>
> /* Timer */
> #ifdef CONFIG_MCFTMR
> #define CONFIG_SYS_UDELAY_BASE ? ? ? ? ?(MMAP_DTMR0)
> #define CONFIG_SYS_TMR_BASE ? ? ? ? ? ? (MMAP_DTMR3)
> #define CONFIG_SYS_TMRPND_REG ? ? ? ? ? (((volatile int0_t
> *)(CONFIG_SYS_INTR_BASE))->iprl0)
> #define CONFIG_SYS_TMRINTR_NO ? ? ? ? ? (INT0_LO_DTMR3)
> #define CONFIG_SYS_TMRINTR_MASK (INTC_IPRL_INT22)
> #define CONFIG_SYS_TMRINTR_PEND (CONFIG_SYS_TMRINTR_MASK)
>
> #define CONFIG_SYS_TMRINTR_PRI ? ? ? ? ?(0) ? ? ? ? ? ? /* Level must
> include inorder to work */
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> #define CONFIG_SYS_TIMER_PRESCALER ? ? ?(((gd->bus_clk / 1000000) - 1) << 8)
> #endif
>
> According to MCF5271 RefMan Rev 2 (07/2006) page 13-12,
> I think this means that the interrupt, although unmasked, have a level 0,
> priority 0,
> which essentially disables it.
>
> What should be the proper value? (0x09) will make it level 1, priority 1, is
> this ok?
> Or am I chasing the wrong rabbit?
>
> Thanks for your time
>
> - Richard
>

[U-Boot] Coldfire: MCF5271: Periodic HW watchdog petting and sleep function does not work.

[Richard Retanubun]

TC Liew wrote:
> Richard,
> 
> I used 6 for most platforms. 1 is lowest priority - 7 - is the highest.

Got it, thanks TC, I set it similar to the other platform (x1E):

A patch for the timer interrupt that fixes the sleep command is submitted on a separate thread.

I have also submitted a patch for the periodic HW watchdog reset-ing.

If you'd like to continue the discussion, let's do it on the respective patch threads.

Richard