Searching \ for '[PIC]: Osccal' 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/microchip/devices.htm?key=pic
Search entire site for: 'Osccal'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Osccal'
2001\05\09@204337 by David VanHorn

flavicon
face
I can ask PIC questions here too, right?


Ok, Osccal.
I know it hides in the last byte of romspace.
How do I tell the assembler to not overwrite it?

Presumably something like
 org 03ff
 ds

?
--
Dave's Engineering Page: http://www.dvanhorn.org
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\05\09@212720 by Bob Ammerman

picon face
David:

If you don't include any reference to 0x3FF then the assembler won't output
code to be loaded there.

Unfortunately, many programmers do one or both of the two following things,
either of which will screw you:

1: The write the whole address of the chip, whether the HEX file contains
the addresses or not (they write all 1 bits to unused locations).

2: They erase the entire chip before writing (which for many PICs is really
the only option).

PICSTART, for example, gets around this by giving you a "calibration
constants" window into which you can type the correct value just before
programming a chip.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

{Original Message removed}

2001\05\09@213125 by David VanHorn

flavicon
face
At 09:22 PM 5/9/01 -0400, Bob Ammerman wrote:
>David:
>
>If you don't include any reference to 0x3FF then the assembler won't output
>code to be loaded there.
>
>Unfortunately, many programmers do one or both of the two following things,
>either of which will screw you:
>
>1: The write the whole address of the chip, whether the HEX file contains
>the addresses or not (they write all 1 bits to unused locations).
>
>2: They erase the entire chip before writing (which for many PICs is really
>the only option).
>
>PICSTART, for example, gets around this by giving you a "calibration
>constants" window into which you can type the correct value just before
>programming a chip.

Are you telling me that to program pics in production, I have to read,
modify, write the code for EACH chip?

I was looking for some directive to tell the assembler not to use that
location.

--
Dave's Engineering Page: http://www.dvanhorn.org
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\05\09@220145 by Tony Nixon

flavicon
picon face
David VanHorn wrote:

> Are you telling me that to program pics in production, I have to read,
> modify, write the code for EACH chip?
>
> I was looking for some directive to tell the assembler not to use that
> location.

Blank chips should have the OSCCAL in the last address.

If your ASM code does not overwrite this address then it won't be
touched, UNLESS your programmer writes blank (0x3FFF or 0x0FFF) data to
the chip.

If your programmer skips addresses with blank data then there is no
problem.

Perhaps put something like this at the end of your ASM code...

       IF $ = MAXROM
       ERROR "OSCCAL Overwritten"
       ENDIF

Where MAXROM is the last ROM address + 1, eg 0x0200 for 12C508


--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
spam_OUTsalesTakeThisOuTspambubblesoftonline.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\05\09@232632 by Sean H. Breheny

face picon face
Hi Dave,

I think you have to read it out, take note of it, and then re-program it
when writing to the chip.

Sean

At 07:42 PM 5/9/01 -0500, you wrote:
{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\05\09@233306 by David VanHorn

flavicon
face
At 11:26 PM 5/9/01 -0400, Sean H. Breheny wrote:
>Hi Dave,
>
>I think you have to read it out, take note of it, and then re-program it
>when writing to the chip.

How the HELL do people mass-produce with these chips then??

--
Dave's Engineering Page: http://www.dvanhorn.org
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\05\09@233902 by Tony Nixon

flavicon
picon face
David VanHorn wrote:
>
> At 11:26 PM 5/9/01 -0400, Sean H. Breheny wrote:
> >Hi Dave,
> >
> >I think you have to read it out, take note of it, and then re-program it
> >when writing to the chip.
>
> How the HELL do people mass-produce with these chips then??

If you don't overwrite the value, then there's no need to worry about
it.

--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
.....salesKILLspamspam@spam@bubblesoftonline.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\05\09@234332 by David VanHorn

flavicon
face
>
>If you don't overwrite the value, then there's no need to worry about
>it.

Ok, so how do I assure that I don't?

Given that I have a single soucefile that assembles to six different
targets, and many optional includes?

--
Dave's Engineering Page: http://www.dvanhorn.org
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\05\09@234339 by David VanHorn

flavicon
face
>
>If your programmer skips addresses with blank data then there is no
>problem.

So maybe I'm not hosed?

>Perhaps put something like this at the end of your ASM code...
>
>         IF $ = MAXROM
>         ERROR "OSCCAL Overwritten"
>         ENDIF
>
>Where MAXROM is the last ROM address + 1, eg 0x0200 for 12C508

Looks plausible, but MPASM dosen't like it.

--
Dave's Engineering Page: http://www.dvanhorn.org
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\05\10@003800 by Bob Ammerman

picon face
----- Original Message -----
From: "David VanHorn" <dvanhornspamKILLspamCEDAR.NET>
To: <.....PICLISTKILLspamspam.....MITVMA.MIT.EDU>
Sent: Wednesday, May 09, 2001 9:30 PM
Subject: Re: [PIC]: Osccal


> At 09:22 PM 5/9/01 -0400, Bob Ammerman wrote:
> >David:
> >
> >If you don't include any reference to 0x3FF then the assembler won't
output
> >code to be loaded there.
> >
> >Unfortunately, many programmers do one or both of the two following
things,
> >either of which will screw you:
> >
> >1: The write the whole address of the chip, whether the HEX file contains
> >the addresses or not (they write all 1 bits to unused locations).
> >
> >2: They erase the entire chip before writing (which for many PICs is
really
{Quote hidden}

No, that is not the case.

An OTP PIC comes preprogrammed from the factory with the correct OSCCAL
value.  The rest of the chip is empty (erased).

mChips programmer software respects that location and doesn't touch it.

So, you just make sure your source code doesn't explicitly load anything
into the cal. constants and it all just works.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)


> --
> Dave's Engineering Page: http://www.dvanhorn.org
> Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.
>
>

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2001\05\10@003822 by Bob Ammerman

picon face
Try

   IF $ >= MAXROM

instead.

Or just look at the listing file and be sure it doesn't hit the last
location.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

{Original Message removed}

2001\05\10@003830 by Tony Nixon

flavicon
picon face
David VanHorn wrote:
>
> >
> >If your programmer skips addresses with blank data then there is no
> >problem.
>
> So maybe I'm not hosed?
>
> >Perhaps put something like this at the end of your ASM code...
> >
> >         IF $ = MAXROM
> >         ERROR "OSCCAL Overwritten"
> >         ENDIF
> >
> >Where MAXROM is the last ROM address + 1, eg 0x0200 for 12C508
>
> Looks plausible, but MPASM dosen't like it.

Oops, should be...

        IF $ == MAXROM
        ERROR "OSCCAL Overwritten"
        ENDIF


I just tested it and it reports an error if ROM location 0x01FF can be
written to from the ASM code.

--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
salesspamspam_OUTbubblesoftonline.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\05\10@010036 by David VanHorn

flavicon
face
At 11:58 PM 5/9/01 -0400, Bob Ammerman wrote:
>Try
>
>     IF $ >= MAXROM

That's got it.


>Or just look at the listing file and be sure it doesn't hit the last
>location.

Trusting programmers to "respect" something makes me nervous.
Making hexfiles that don't put anything there, makes me feel better.
--
Dave's Engineering Page: http://www.dvanhorn.org
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\05\10@044318 by Roman Black

flavicon
face
David VanHorn wrote:
>
> At 11:58 PM 5/9/01 -0400, Bob Ammerman wrote:
> >Try
> >
> >     IF $ >= MAXROM
>
> That's got it.
>
> >Or just look at the listing file and be sure it doesn't hit the last
> >location.
>
> Trusting programmers to "respect" something makes me nervous.
> Making hexfiles that don't put anything there, makes me feel better.


David, it is simpler than you think, the
blank PICs come with all bits as ONEs.
The programmer blows all the correct bits
from ONEs to ZEROs, and with a OTP chip this
cannot be reversed.

So all you have to do is make sure you are
writing 3FF (or whatever, all ONEs) to the
osccal byte and no bits there will be changed.
ie, the oscal value stays there intact.

Hope that all makes sense. Microchip cover this
quite well in their ICSP guide (appnote?) they
discuss re-programming OTP chips in the field
which can be done indefinitely (while memory
space remains) because you put a jump at the
start of memory, with lots of 3FF bytes. Then
each time you reprogram it you just put a new
jump before the old one. So if you have a 1k
12C509 with 100 byte program, you can re-program
it about 9 times using this system. Pretty
clever. :o)
-Roman

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2001\05\10@090728 by Olin Lathrop

face picon face
> Ok, Osccal.
> I know it hides in the last byte of romspace.

Not exactly.  The last instruction is a MOVLW with the factory determined
OSCAL value.  The machine starts executing there, then wraps to location 0.
This has the net effect of loading W with the factory OSCAL value on power
up.

> How do I tell the assembler to not overwrite it?

Just don't put anything there.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, spamBeGoneolinspamBeGonespamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservEraseMEspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2001\05\10@090744 by Olin Lathrop

face picon face
> Are you telling me that to program pics in production, I have to read,
> modify, write the code for EACH chip?

No, just don't program over the last location.

> I was looking for some directive to tell the assembler not to use that
> location.

You can just not put anything there, or you could set up the linker sections
as if the last location didn't exist.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, RemoveMEolinspamTakeThisOuTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservEraseMEspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2001\05\10@100838 by Olin Lathrop

face picon face
> Trusting programmers to "respect" something makes me nervous.
> Making hexfiles that don't put anything there, makes me feel better.

You could post-process the hex file if you really wanted to be sure.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, EraseMEolinspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservEraseMEspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body


2001\05\10@100842 by Olin Lathrop
face picon face
> So all you have to do is make sure you are
> writing 3FF (or whatever, all ONEs) to the
> osccal byte and no bits there will be changed.
> ie, the oscal value stays there intact.

This will leave the OSCAL data intact, but should produce errors on verify.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, RemoveMEolinspam_OUTspamKILLspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\05\10@142143 by Peter L. Peres

picon face
You don't tell the assembler nothing and it generates no code for this
line. The programmer then skips it. Assuming you have the right programmer
of course. In theory, if you set it to FFFh then the programmer should try
to program a FFF into something lower and fail (this is if you have a
noncompliant programmer with strange software).

Peter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspamspamspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body


2001\05\10@142150 by Peter L. Peres

picon face
> At 11:26 PM 5/9/01 -0400, Sean H. Breheny wrote: >Hi Dave, > >I think
> you have to read it out, take note of it, and then re-program it >when
> writing to the chip.

You want to read the chip before writing anyway (you can read just one
location if you want), and twice afterwards, yes ? But that is not the
point. A programmer should NOT try to program a location for which there
is no data in the obj file. Ever wondered why there are is no FF data in
object files ? (hint:erased cells in PICs and (E)EPROMs read FF).

>How the HELL do people mass-produce with these chips then??

Mostly by using OPEN SOURCE programmers so they can do with them whatever
is needed. I think ;-).

Peter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\05\10@150045 by David VanHorn

flavicon
face
At 07:59 PM 5/10/01 +0300, Peter L. Peres wrote:
> > At 11:26 PM 5/9/01 -0400, Sean H. Breheny wrote: >Hi Dave, > >I think
> > you have to read it out, take note of it, and then re-program it >when
> > writing to the chip.
>
>You want to read the chip before writing anyway (you can read just one
>location if you want), and twice afterwards, yes ?

Why would I read it before writing, (Other than to play with osccal)?
The normal cycle with every other part I've worked with, is to buy them
blank, and simply program them.

>But that is not the
>point. A programmer should NOT try to program a location for which there
>is no data in the obj file. Ever wondered why there are is no FF data in
>object files ? (hint:erased cells in PICs and (E)EPROMs read FF).

True. If there is nothing in the hex that tells it to write there, then it
shouldn't do that.
This does also depend on your definition of "blank", but I'd hope the
programmer knows about that.
So, why does uChip allow me to overwrite this critical location by default?
Seems to encourage problems.
Seems simple enough to sense that the directive to use internal osc is set,
so just pretend the chip is one byte smaller.

I would understand, if I needed a special directive, as is done with the
config word, to overwrite this critical data.
I would probably understand if they just didn't let me write to that cell.
If microchip designed cars, then the brake master cylinder would be located
in the passenger seat, with quick-disconnects.  Me, I want it under the
hood, and needing wrenches to remove.

>Mostly by using OPEN SOURCE programmers so they can do with them whatever
>is needed. I think ;-).

My experience in production is with things like multiple Data-I/O 20 wide
gang-bangers.
They aren't open-source.


--
Dave's Engineering Page: http://www.dvanhorn.org
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservSTOPspamspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2001\05\11@003837 by Dwayne Reid

flavicon
face
At 08:30 PM 5/9/01 -0500, David VanHorn wrote:

>Are you telling me that to program pics in production, I have to read,
>modify, write the code for EACH chip?

Nope - at least with the PicStart Plus.  Programmer -> Program/Verify:
uncheck the 'Calibration Value' box.

dwayne



Dwayne Reid   <spamBeGonedwaynerSTOPspamspamEraseMEplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 17 years of Engineering Innovation (1984 - 2001)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu


2001\05\11@053423 by Peter L. Peres

picon face
> Why would I read it before writing, (Other than to play with osccal)?
> The normal cycle with every other part I've worked with, is to buy them
> blank, and simply program them.

You are a good, trusty guy Dave. ;-) If I'll pay you $1.000.000 in $100
bills would you count the money or not ? ;-) (I do NOT offer to pay you,
just pretend).

The cost to find a bugged product farther down the assembly line than at
the programmer is larger than the extra time spent reading the chip to do
*blank verification* as per Mchip programming spec. Incidentally the blank
verification should be done at Vddmax and Vddmin, so twice ?

Peter

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspamEraseMEmitvma.mit.edu


2001\05\11@085408 by David VanHorn

flavicon
face
>
>The cost to find a bugged product farther down the assembly line than at
>the programmer is larger than the extra time spent reading the chip to do
>*blank verification* as per Mchip programming spec. Incidentally the blank
>verification should be done at Vddmax and Vddmin, so twice ?

My question remains.
WHY am I reading the chip??

If it's non-blank, then if the zeroed bits hit zeroes in my code, I don't care.
If they hit 1s in my code, my programmer will alert me.

--
Dave's Engineering Page: http://www.dvanhorn.org
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

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


2001\05\12@104445 by Peter L. Peres

picon face
> My question remains.
> WHY am I reading the chip??

Perhaps because it is a PART OF THE PROGRAMMING SPEC as per manufacturer
documentation ? Actually I see this only in the 16C5X programming method
(first step is: Blank Check @Vdd = Vdd min) (Microchip Databook 1994 ;-).

Peter

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


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