re "Brand X" Microprocessor startup problems.

> Sounds like the phase-gain characteristics of the
> active element comprising the on-board osc
> have changed ... do you have a means to test this?
>
> ... simple feedback resistor, inject a signal and
> observe the 'phase-gain relationship' at several
> different frequencies ...
>

I have no formal test equipment to test this but could devise something if
it seemed liable to help.
However,

    The Taiwanese manufacturer has tried "all the usual" tricks to make the
oscillator start properly. The best solution they found was a 1M across the
oscillator pins and a 56r in series with the crystal. The latter is lower
than is usually suggested and the 1M  is typical. As is usually the case,
the processor has an internal feedback resistor which is supposed to be
adequate.

       Microprocessor oscillators are meant to oscillate. While the best
capacitors for the task need to be chosen and while these will be affected
by crystal requisite load capacitance and while crystal "activity" and other
arcane parameters can and do change with batch, the oscillators are meant to
oscillate. With suitable experiment (or calculation if suitable instruments
are used) a NORMAL solution should work reliably. This processor doesn't do
what it should. As I noted in my original comment, this is in "certain
circumstances". The application in question has "interesting" power supply
rise characteristics for technically good and sufficient reasons. (These
could be altered with suitable cost and effort). These contribute to the
problem. The spec sheet places no limitations on supply rise times. A
properly designed internal reset circuit will allow a processor to start up
cleanly and reliably regardless of supply behaviour. As the processor in
question has NO external rest line it is essential that the internal
circuitry is able to handle anything it encounters. [[ Another version of
this family had a similar problem about 2 years ago when, in one batch only,
if the supply was raised VERY slowly, the oscillator would start but the
processor would not. Very repeatable and limited to one date coda. I suspect
that a similar but not identical problem is occurring here.]]

As noted initially, the problem appears to be a form of latchup and is very
possibly based on voltages (and their impedance*) at various pins during
restart. Most "bad" processors will start when power is first applied and
not subsequently unless a suitable delay is allowed to replicate initial
conditions.

My aim was not to analyse the problem I have (but yer all welcome to IF you
can fix it more cheaply than by using a 22 uH inductor) but to note the fact
that such an arrangement may have its uses as we were talking about RL based
oscillators (which this isn't an example of :-) . .

> If the placement of the inductor was across the
> 'inverter' that comprises the active osc device,
> you have effectively shunted the DC (and low
> freq. gain) gain of that stage ...

Indeed! The 1 ohm inductor resistance will do this quite well :-) In the
PCBs that I have been sent there is a 56r is series with the crystal and the
22 uH is across the crystal so this provides a small dc component across the
oscillator proper. However, even with this 56r shorted out )so 1r coil
across oscillator pins) the results were essentially identical. (A series r
is usually used to reduce oscillator signal magnitude with a very active
crystal to prevent crystal damage. In this case the value has been selected
by trial by the Taiwanese to get best startup results.)


    Russell McMahon

* - the circuit includes a Sigma-Delta converter which uses a 1uF capacitor
which is directly from a processor pin to ground. As this could have been
providing a source of low impedance dc at restart I tried replacing it with
a much smaller value cap during testing - no change in results.

Similarly, connecting all pins to Vdd with Schottky diodes produces a most
interesting looking result but no practical improvement in performance.

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu