Searching \ for 'Oscillator calibration rewriting...' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page:
Search entire site for: 'Oscillator calibration rewriting...'.

Truncated match.
PICList Thread
'Oscillator calibration rewriting...'
1998\02\26@223043 by Mauro, Chuck

Yes, it can be updated anywhere in your program.  But, don't forget to
use a MOVWF OSCCAL at the very beginning of your program (@ address 0)
to establish the proper factory calibration (the data sheet explains
this).  It sounds like you are definitely experiencing a reset problem.
The brown-out circuit may be your only choice.

-Chuck Mauro

> {Original Message removed}

1998\02\27@195206 by Mike Keitz

picon face
On Thu, 26 Feb 1998 17:42:27 -0800 "Mauro, Chuck"
<spam_OUTChuck.MauroTakeThisOuTspamKLA-TENCOR.COM> writes:
>Yes, it can be updated anywhere in your program.  But, don't forget to
>use a MOVWF OSCCAL at the very beginning of your program (@ address 0)
>to establish the proper factory calibration (the data sheet explains
>this).  It sounds like you are definitely experiencing a reset

You should keep the factory value somewhere else in your program (a
logistical nightmare), and periodically do movlw <value>/movwf OSCCAL.
Second best would be to copy the factory value to RAM as well as to the
OSCCAL register at the start of the program, then periodically copy it
back to OSCCAL.  But if a glitch hits hard enough to trash the RAM, this
won't work.

You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at
Or call Juno at (800) 654-JUNO [654-5866]

1998\02\27@224032 by Mauro, Chuck

In this business, you have to draw the hard line occasionally on
problems like these, and unfortunately we have to make assumptions as
you pointed out below.  That's one of the engineering challenges we all
face:  making the right tradeoff when there are no great choices...

I agree with you Mike - depending on the product and the circumstances,
OSCCAL may or may not need to be refreshed periodically.  For EMC
considerations (especially in the susceptibility arena), it's things
like properly knowing when and how to refresh a critical register that
make life difficult...

Chuck Mauro

> {Original Message removed}

1998\02\27@235345 by Richard Nowak

picon face
(warning: long post -- but no cows for Gary's sake)

Some observations:

There has been some discussion recently about RAM getting corrupted I/O
registers getting messed up and that we should all include somewhere in the
firmware loop various degrees of re-initialization so the processor can get
back up on its feet after a hit.

I'm not going to tell you not to do that stuff but here are some tips I have
learned over the years to minimize the hits. I'm probably not going to state
anything that you folks don't already know, but there may be a few new
people out there that might benefit. I'm not covering everything either
because I don't know everything.

Embedded designs are not easy to troubleshoot in the first place and
sometimes you don't know if it's the hardware, the software, the firmware,
the compiler, the cable, version incompatibilities, the power supply, timing
problems, the phase of the moon etc., and repairing each bug can be an
adventure in itself. So the approach I use is to try to get it right the
first time (short cuts rarely are).

Here's a process I use:

1)  Analyze the requirements. Articulate the problem you are trying to
solve. A process I like to use is a simple one. Write a paragraph or so on
what your widget is supposed to do. Get it to a point where someone else can
read it and understand what you are trying to do without any coaching on
your part.

2)  Now take out two different colored HI-LIGHTERS and mark all the verbs
with one color and all the nouns with another. The nouns are the data. The
verbs are the processes. Collect the verbs (processes) into four streams (a)
low level (implementation dependent) input (b) high level (logical) input
(c) high level (logical) output and (d) low level (implementation dependant)
output. Collect the nouns (data) with the appropriate verbs and identify
them as either input(s) or output(s) to that process. Identify cohesive
functions by collecting similar processes within each stream.

This will help establish a functional hierarchy for your project and will
enable you to understand what needs to be done. Unfortunately it will not
reveal to you *when* things need to be done and this is the major challenge
of embedded controller designs i.e. real time systems, but if you don't know
completely what needs to be done you will quickly learn that doing the wrong
thing at the "right" time is equally useless.

3)  Take your time on the hardware design. Be conservative. You can always
eliminate things later after you get it working. Have someone else review
it. Ask her what's wrong with it. Try to visualize how your design might
fail. Incorporate mechanisms to handle the failure cases.

4)  Go directly to a PCB four layer (or more) board if you can.
Troubleshooting a rat's nest is no fun at all and you may end up spending a
lot of time learning nothing. As you acquire more experience and confidence
in your ability this won't seem so shocking.

Use the outer two layers for signal traces (most modifications occur here).
Inner layers for power and ground. Analog and digital ground eventually get
tied together someplace but try to isolate the analog circuits from the
digital ones as much as possible.

Provide layout for an addition chip (20 pin dip) just in case you need to
add a gate, a flip-flop, or other components. Provide in the layout any
by-pass caps that may be required there as well. Pay attention as to what
you are "bypassing" and where. You can't get something clean without getting
something else dirty.

5)  Pay attention to shared current paths in both the power traces and
ground traces.
If you're controlling high current loads, separate power supplies may be in
order. What you don't want is a change in load current to produce a
"recognizable" change on an input line somewhere else. A separate regulator
for the PIC circuitry could be prudent.

6)  Bypass every chip's power pin to ground using a 0.01-0.1 uF cap.

7)  Isolate the PIC as much as possible with buffers.

8)  Always use line drivers/receivers when going off board. Differential is
best. Lines should be properly terminated. If TTL, reduce pullup voltage
with diodes to limit voltage swings. Ribbon cable may not be a good choice
in faster systems.

9)  Use shielded cables. Board connectors should have a metal shell and tied
to the PCB ground plane.

10) Develop the firmware in small pieces. Ensure that each piece works
before going to the next step. Don't try to do too much at once.

11) Run the design at the slow speeds to start. When everything seems to be
working then start experimenting with fast.

12)  If possible use polling in the beginning. Interrupt driven stuff can
drive you nuts enough when that alone is not quite right.

13)  Shield the product (metal enclosure).

14) Incorporate a display in your design (leds or other) to provide visual
feedback as the PIC rips through the code.

In closing ...

I've always had a lot of respect for people who do this kind of work. It's
not easy -- it can be very frustrating, but a working design tells a lot
about the person who made it work.


At 07:34 PM 2/27/98 -0500, you wrote:
{Quote hidden}

= Abolish the Income Tax! Fire the IRS! =
=                  =

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...