Searching \ for 'Nailing this down (Was 12C508 trouble)' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=nailing+down+was
Search entire site for: 'Nailing this down (Was 12C508 trouble)'.

Truncated match.
PICList Thread
'Nailing this down (Was 12C508 trouble)'
1997\02\01@161855 by Todd Peterson

picon face
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:
---------------------------------------

1FFE   0C40   movlw 0x40
0000   0025   movwf 0x5
------ the two above are the important ones, the code following is other init.
0001          clrf 0x4
0002          movlf 0x9
0003          movlw 0xf
0004          moxwf 0x7
             etc.


The following code DOES correctly set OSCCAL (notice two duplicate lines added)
-------------------------------------------------------------------------------

1FFE   0C40   movlw 0x40
0000   0025   movwf 0x5

0001          clrf 0x4
0002          movlf 0x9

0003   0C40   movlw 0x40     \
0004   0025   movlw 0x5      / Repeating these two lines DOES load OSCCAL

0005          movlw 0xf
0006          moxwf 0x7
             etc.


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?

       -Todd Peterson

1997\02\03@213347 by John Payson

picon face
> 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?

1997\02\05@130429 by Scott Fink

picon face
Todd,

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?).

Best Regards,
Scott Fink
Microchip Technology

______________________________ Forward Header __________________________________
Subject: Nailing this down (Was 12C508 trouble)
Author:  Todd Peterson <spam_OUTelabTakeThisOuTspamNETINS.NET> at Internet_Exchange
Date:    2/1/97 5:09 AM


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:
---------------------------------------

1FFE   0C40   movlw 0x40
0000   0025   movwf 0x5
------ the two above are the important ones, the code following is other init.
0001          clrf 0x4
0002          movlf 0x9
0003          movlw 0xf
0004          moxwf 0x7
             etc.


The following code DOES correctly set OSCCAL (notice two duplicate lines added)
-------------------------------------------------------------------------------

1FFE   0C40   movlw 0x40
0000   0025   movwf 0x5

0001          clrf 0x4
0002          movlf 0x9

0003   0C40   movlw 0x40     \
0004   0025   movlw 0x5      / Repeating these two lines DOES load OSCCAL

0005          movlw 0xf
0006          moxwf 0x7
             etc.


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?

       -Todd Peterson

1997\02\11@105153 by mike

flavicon
picon face
In message  <.....199702040222.UAA14939KILLspamspam@spam@Jupiter.Mcs.Net> PICLISTspamKILLspamMITVMA.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.

(I'd try it myself, but my PC has been taken away for repair.)


Regards,



Mike Watson
--
Mayes uk

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