On Mar 14, 2010, at 8:11 PM, Robert Adsett wrote:
> On 3/14/2010 8:58 PM, Cat C wrote:
> > If you're gonna propose a reset chip, or other circuitry to get a
> reset other ways, why? This works fine.
>
> I would recommend at least testing with a proper reset chip.
>
> Why? Simply to try to narrow down the problem. Problems like this
> worry me, they indicate something going on that is not understood.
> Such
> things have a nasty habit of coming back in another form avoiding the
> initial workaround.
>
> This 'feels' like a power on reset problem and built-in micro-
> controller
> power on reset circuits are notorious for having holes in some
> corner of
> performance. An external reset chip would eliminate that possibility.
> Leaving a reset chip in the design is open to question, testing with a
> reset chip at his point I would consider mandatory.
>
> My other immediate suspicion in cases like this is initialization
> code.
> Although given your experience with this processor family I cannot
> imagine what you could be leaving out (and I have no suggestions to
> offer).
>
> My best suggestion is to be worried.
>
> Robert
>
>
>
I agree with Robert. While watchdog reset may "work", to me, it is
indicative that something is wrong. Wrong because it should not be
needed and because there are many,. many, apps out there, that do fine
without resorting to it. The fact that all this is necessary indicates
to me that there is something happening that is unrecognized, not
understood, etc. If this is the case, then you do NOT know what else
is happening or what else might happen. Watchdog may "fix" the "hung
SDI" problem, but what about the other, so far unrecognized things?
And, program complexity is only an excuse for not solving it. There
should be NO reason for a complex program to have this problem than a
simple one, other than the fact that it is harder to debug.
I have been through situations roughly like this. They were always
painful to dissect and always took an inordinate amount of time. But,
every one had other problems besides the one that was the most
obvious. Sometimes, they were errors like an interrupt happening in
the middle of what SHOULD have been an atomic operation. Sometimes,
they were mis-configured hardware. Sometimes, it was code that
attempted to follow an incorrect understanding of how some bit of
hardware really works. Occasionally, it was a state machine with an
incorrect state name used at some point in the machine. But, every one
was really, really, obscure.
I hope you take time to work it out. Frankly, I would not trust
operation of the device, left as it is.
Jim Wagner
Oregon Research Electronics
[Non-text portions of this message have been removed]