Rather than me seperatly e-mail those who sent me private e-mail about the
12C508 & their trouble with the JW version's not taking a cal. constant, I
wanted to post something that might help you out.

Please notice that the trouble is not that the value doesn't work when
OSCCAL is loaded from with the main part of the program; changing it 'on the
fly' within the main prog loop seems to work fine. The problem is that (at
least for some of us), setting it with the first two bytes executed after
powerup does not work.

I have isolated it down to two trivial cases:

This DOES NOT WORK on some JW 12C508's:
---------------------------------------

This points to a powerup problem, at least in my mind. Also, notice that to
make this woek, you need to KNOW the calibration constant, so it won't work
well for mass-programming OTP's. Why would the value stay in OSCCAL when
written with instructions several cycles after powerup, but not when written
on the first two instructions?

> This points to a powerup problem, at least in my mind. Also, notice that to
> make this woek, you need to KNOW the calibration constant, so it won't work
> well for mass-programming OTP's. Why would the value stay in OSCCAL when
> written with instructions several cycles after powerup, but not when written
> on the first two instructions?

Hmm... others have suggested a problem with old initialization code intended
for other parts which may clear the calibration register incorrectly; it may
also be a power-up problem as you suggest. For fun, however, what if you try
something like this:

I was unable to duplicate your problem and all of my parts worked here. We have
also done some extensive characterization of the part and have not seen anything
like this (watch for the next rev of the datasheet).

Which programmer and version of software and firmware are you using, also
compiler? Maybe the calibration instruction location 0x1ff doesn't really
contain what you think it does. Also watch for '508 vs '509 memory size, I
don't think this is your problem, but it could be a gotcha.

I notice in your listing below you show the address of the calibration
instruction as 1FFE, hopefully this is a typo and you really meant 01FF.

I noticed somewhere in this thread some guessing going on, so I will give some
more info on the oscillator which will be in the new data sheet. Only the upper
nibble is significant, OSCCAL is reset to 7Xh on any reset (including wake up
from change, which is really a reset on change). A higher number in OSCCAL
yeilds a higher clock speed (about 4.5nS per count).

Also remember, and tell your disti, that the errata on the rev A0 parts (all are
marked ES) is only for the OSC1 pin to become an input during sleep, it does NOT
affect the internal oscillator frequency in any way. There are no KNOWN errata
on the internal RC oscillator.

If you still can't resolve your abnormality, reply to me directly (you can copy
the list and I will too, not trying to hide anything) as I am not on the list,
although I do monitor the SIG on the BBS, our official answer line. You can
also call the microchip 800 number and tell them I said it was OK to patch you
through to me directly (you didn't think I was going to post my direct number on
the PICLIST did you?).

Rather than me seperatly e-mail those who sent me private e-mail about the
12C508 & their trouble with the JW version's not taking a cal. constant, I
wanted to post something that might help you out.

Please notice that the trouble is not that the value doesn't work when
OSCCAL is loaded from with the main part of the program; changing it 'on the
fly' within the main prog loop seems to work fine. The problem is that (at
least for some of us), setting it with the first two bytes executed after
powerup does not work.

I have isolated it down to two trivial cases:

This DOES NOT WORK on some JW 12C508's:
---------------------------------------

This points to a powerup problem, at least in my mind. Also, notice that to
make this woek, you need to KNOW the calibration constant, so it won't work
well for mass-programming OTP's. Why would the value stay in OSCCAL when
written with instructions several cycles after powerup, but not when written
on the first two instructions?

In message <.....199702040222.UAA14939KILLspam@spam@Jupiter.Mcs.Net> PICLISTKILLspamMITVMA.MIT.EDU
writes:
> > This points to a powerup problem, at least in my mind. Also, notice that to
> > make this woek, you need to KNOW the calibration constant, so it won't work
> > well for mass-programming OTP's. Why would the value stay in OSCCAL when
> > written with instructions several cycles after powerup, but not when written
> > on the first two instructions?
>
> Hmm... others have suggested a problem with old initialization code intended
> for other parts which may clear the calibration register incorrectly; it may
> also be a power-up problem as you suggest. For fun, however, what if you try
> something like this:
>
> 0FFF: movlw $C0 ; Or whatever constant
> 0000: movwf $1F ; Not the calibration port!
> ...
> 00xx: movf $1F,w ; Read back the value above
> 00xx: movwf $05 ; ...and store it to the speed register
>
> Does something like that work any better?
>

Did anyone try this? I'm interested to know if this is a
good work around.