I have run into a small problem that I am sure can be easily solved.
I purchased a 12C509JW part. I noted the OSCAL value a address H'03FF'
as H'0CB0'. As I am using the INTRC I knew I would need the number after
I erased the chip. So far, so good.
I programmed it (with the first instruction being MOVWF OSCCAL) and ran
the program. I then modified the code and erased the part. However, I
am now stumped as to how to get the value back into the correct location.
Looking at the Microchip documentation DB can only be used to store
eight-bits. Thus DB H'0CB0' seems wrong.
ORG H'03FF'
DW H'0CB0'
should try to store the two bytes at H'03FF' and H'0400' if I read the
doc's right.
I have to admit that I haven't tried any of these remedies as I am hoping
that the voice of experience will let me know the correct way before the
day is out.
How do I get the OSCCAL value back at H'03FF' in the JW part?
I sort of promised (bragged is more like it) a working prototype on
Monday so I am in a sweat. A reply to my E-mail address would be
appreciated as I get the DIGEST form of the PICLIST. Remember about
taking out the '.NS' from my return address.
Many thanks in advance,
Michael
REMOVE THE .NS (NO SPAM) FROM MY ADDRESS TO REPLY
*************************************************************************When th
e way of the Tao is forgotten, kindness and ethics must be taught.
Men must learn to pretend to be wise and good. -- Lao Tzu
*************************************************************************
> I purchased a 12C509JW part. I noted the OSCAL value a address H'03FF'
> as H'0CB0'. As I am using the INTRC I knew I would need the number after
> I erased the chip. So far, so good.
> Looking at the Microchip documentation DB can only be used to store
> eight-bits. Thus DB H'0CB0' seems wrong.
'0xCB0' is a movlw instruction with data attached:
On Fri, 19 Jun 1998 17:54:03 -0400 RHS Linux User
<spam_OUTchipTakeThisOuTCROWSNEST.AEUG.ORG> writes:
>On Fri, 19 Jun 1998, Michael Ghormley wrote:
>
>> I purchased a 12C509JW part. I noted the OSCAL value a address
>H'03FF'
>> as H'0CB0'. As I am using the INTRC I knew I would need the number
>after
>> I erased the chip. So far, so good.
>
>> Looking at the Microchip documentation DB can only be used to store
>> eight-bits. Thus DB H'0CB0' seems wrong.
If you're using MPLAB, pull don the "Window" bar, open the "Calibration
Values" window and punch the value in there. If you have only one chip,
it would be simpler yet to just put MOVLW h'B0' then MOVWF OSCCAL at
address 0. When you go back to OTP chips with the value already in
place, take the MOVLW out or replace it with a NOP.
_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]
Perhaps it is the documentation. Perhaps it is my skimming it rather
than reading it. Most likely it is a combination of the two.
No matter what directive I tried, DATA, DB, DW, DE (thanks to Thomas
McGahee), I could not get H'0CB0' into address H'03FF'. The H'B0'
portion was no problem. Getting the H'0C' part into the high bits was
where I was stuck.
After trying every directive that I could think of, my second plan was to
see if I could be lucky enough to find a MASM instruction that might
compile to the needed bits. And there was! Lucky me!
The instruction MOVLW compiles to H'Cxx' where the xx is the literal.
Then, s-l-o-w-l-y it dawned on me. The 508/509 chip takes its first
instruction -- not from H'000' as we might expect -- but from the last
memory location at H'03FF'. Thus, after executing this MOVLW, it rolls
over to H'000' with the OSCCAL value in W.
Maybe this is plastered all over the documentation, but I sure didn't see
it!
The final solution:
ORG H'03FF'
MOVLW H'B0'
ORG 0
MOVWF OSCCAL
; the rest of the code
It's easy when you know how, huh? I hope this helps someone else out
there and keeps them from stumbling over this particular stone.
Thanks once again to Thomas McGahee for his quick response about the DE
directive.
Michael
REMOVE THE .NS (NO SPAM) FROM MY ADDRESS TO REPLY
*************************************************************************When th
e way of the Tao is forgotten, kindness and ethics must be taught.
Men must learn to pretend to be wise and good. -- Lao Tzu
*************************************************************************
Michael Ghormley wrote:
> Maybe this is plastered all over the documentation,
> but I sure didn't see it!
I'm afraid it's there alright. I went through the data sheet with
a fine toothed comb the first time I got it.
Microchip PIC12C5XX Data Sheet
Section 7.2.5 INTERNAL 4 MHz RC OSCILLATOR
Page 28 of DS40139B
"In addition, a calibration instruction is programmed into
the top of memory which contains the calibration value for
the internal RC oscillator. This value is programmed as a
MOVLW XX instruction where XX is the calibration value, and
is placed at the reset vector. This will load the W register
with the calibration value upon reset and the PC will then
roll over to the users program at address 0x000. The user
then has the option of writing the value to the OSCCAL
Register (05h) or ignoring it."
See also same page the reset conditions for registers; PC is set to
something which ain't zero.
>I'm afraid it's there alright. I went through the data sheet with
>a fine toothed comb the first time I got it.
I wish I had done the same! I am doing so now, you can bet. d;^)
If only I didn't take the PICLIST in digest form I would have had my
answer when I logged on to ask! The OSCCAL question had been asked and
answered that day.
<SNIP Data Sheet Quote>
Thanks for the additional data. My chips are programmed and all humming
away in the oven. I actually got *outside* this weekend!
Michael
REMOVE THE .NS (NO SPAM) FROM MY ADDRESS TO REPLY
*************************************************************************When th
e way of the Tao is forgotten, kindness and ethics must be taught.
Men must learn to pretend to be wise and good. -- Lao Tzu
*************************************************************************
CROWSNEST.AEUG.ORG> writes:
