MPC83xx watchdog reset board dead lock

Leon Woestenberg leon.woestenberg at gmail.com
Wed Jun 17 20:09:21 EST 2009


Hello all,

On Wed, Jun 17, 2009 at 10:35 AM, Norbert van
Bolhuis<nvbolhuis at aimvalley.nl> wrote:
> Hi Leon,
>
> I doubt if there are working designs for this.
> ...
> In u-boot the watchdog (if enabled with CONFIG_WATCHDOG) is normally
> strobed in the decrementer interrupt routine (timer_interrupt). So
> I guess there's not a big chance it triggers a reset.
> ...
>
Most designs do not care about the watchdog, or only pet in their
non-critical paths... That's not what the watchdog is for.
Also, I don't care about u-boot.

I care about a design where the Flash NOR could be in write mode at
any time when the watchdog triggers, when the hardware is running
critical software.
No lifes in danger when it happens, only jobs, so no biggy :-)


David has been helpful in thinking this through, but we followed-up
offline, and we independently came up with the following design, so
this must therefore work (disclaimer applies).

Note, it DOES require a NOR flash that has a RY/BUSY# pin.

Quoting David Hawkins, who gave a very clear explanation:
---
How about using the RDY/BUSY# pin on the Flash in conjunction
with PORESET#. If the flash is busy, then the processor gets
PORESET#, otherwise, the HRESET# just does its normal thing.

That way PORESET# only ever asserts when you have the
combo of the Flash being busy and HRESET# asserting.

<...>

If you have the Flash BUSY# signal, then this scheme works
great, since using HRESET# low and BUSY# low to create a
PORESET# source is only active until the Flash RESET#
is asserted long enough for it to get out of the BUSY#
state and back into read-array mode.
---

Kudos to David.

I'll be testing the design tomorrow on the reference board, I'll
report results in this thread.


Regards / Groeten,
-- 
Leon


More information about the Linuxppc-dev mailing list