Searching \ for '[PIC]: Up is not UP, Down is not Down, and OSCCA' 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: 'Up is not UP, Down is not Down, and OSCCA'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Up is not UP, Down is not Down, and OSCCA'
2003\02\18@183244 by llile

flavicon
face
I am seeing an interesting problem with the OSCCAL and internal RC
oscillator in a 16F676.  The spec sheet sez that the tolerance on the
internal RC oscillator is +/- 2%, under most any conceivable operating
voltage and temperature.   Compiling under Hitech C.  Operating at 5.0
volts DC at 24degrees C ambient.

I am using parts that are "supposed" to have been programmed with the
correct OSSCAL number.

I consistently measure the oscillator as running about 20-26% too slow in
five consecutive parts.  I measured them several ways, 1. by using a 60
seconds interval based on a  timer1 timeout and a stopwatch ,    2. by
using a series of bcf bsf bcf bsf  statements to toggle a pin, and      3.
by using a loop

do{
       bit_clear(PORTA, 2)
       nop();
       nop();
       bit_set(PORTA,2);
       While(1);

which generates a continuous stream of pulses 6 clocks long (3 up, 3
down).  I find that 6 clocks takes 7.6 uS, about 26% too long.  (note -
bit-clear, bit_set and nop are not defined in HITECH C, but I define them
to do what they say they do)  all these measurements come out 20-26% too
slow.

Now, HITECH C Claims it automatically takes care of the OSSCAL register on
startup.  This is interesting, but I cannot verify it in the listing file,
not being able to locate the applicable code, nor even the powerup psect.

I can think of three causes for unCAL'd OSSCALs:

1. HITECH C ignores the OSCCAL register, contrary to what it says on pg
134 of the manual,

2. MCHIP's calibration is no good, contrary to what it says in the 16F676
datasheet,

3.  I have somehow managed to flub up this measurement despite having
checked it three different ways,

4. My brand new HP scope, just back from factory calibration, is out of
calibration, and my stopwatch is out of calibration by the same amount,
despite having been calibrated against the atomic clock less than 6 months
ago

5. The '676, being a brand new part, has a major silicon bug

6. There is something else going on that is very wierd.


Now, none of these causes seems very likely to me.  Can anyone suggest a
cause that could be more likely?

--Lawrence




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

2003\02\18@190158 by michael brown

picon face
----- Original Message -----
From: <spam_OUTllileTakeThisOuTspamSALTONUSA.COM>
To: <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU>
Sent: Tuesday, February 18, 2003 5:31 PM
Subject: [PIC]: Up is not UP, Down is not Down, and OSCCAL is not CAL'd


> I am seeing an interesting problem with the OSCCAL and internal RC
> oscillator in a 16F676.  The spec sheet sez that the tolerance on the
> internal RC oscillator is +/- 2%, under most any conceivable operating
> voltage and temperature.   Compiling under Hitech C.  Operating at 5.0
> volts DC at 24degrees C ambient.
>
> I am using parts that are "supposed" to have been programmed with the
> correct OSSCAL number.
>
> I consistently measure the oscillator as running about 20-26% too slow
in
> five consecutive parts.  I measured them several ways, 1. by using a
60
> seconds interval based on a  timer1 timeout and a stopwatch ,    2. by
> using a series of bcf bsf bcf bsf  statements to toggle a pin, and
3.
{Quote hidden}

(note -
> bit-clear, bit_set and nop are not defined in HITECH C, but I define
them
> to do what they say they do)  all these measurements come out 20-26%
too
> slow.
>
> Now, HITECH C Claims it automatically takes care of the OSSCAL
register on
> startup.  This is interesting, but I cannot verify it in the listing
file,
> not being able to locate the applicable code, nor even the powerup
psect.
>
> I can think of three causes for unCAL'd OSSCALs:
>
> 1. HITECH C ignores the OSCCAL register, contrary to what it says on
pg
> 134 of the manual,
>
> 2. MCHIP's calibration is no good, contrary to what it says in the
16F676
> datasheet,
>
> 3.  I have somehow managed to flub up this measurement despite having
> checked it three different ways,
>
> 4. My brand new HP scope, just back from factory calibration, is out
of
> calibration, and my stopwatch is out of calibration by the same
amount,
> despite having been calibrated against the atomic clock less than 6
months
{Quote hidden}

Is it possible that the programmer changed it to a different value than
the factory had it set to?

michael

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

2003\02\19@082810 by Olin Lathrop

face picon face
> I am using parts that are "supposed" to have been programmed with the
> correct OSSCAL number.
>
> I consistently measure the oscillator as running about 20-26% too slow
in
> five consecutive parts.  I measured them several ways, ...
>
> Now, HITECH C Claims it automatically takes care of the OSSCAL register
on
> startup.  This is interesting, but I cannot verify it in the listing
file,
> not being able to locate the applicable code, nor even the powerup
psect.

This an easy thing to verify.  The first step would be to write an
assembler program that you know sets OSCCAL properly, then does your 6
cycle loop.  That will immediately tell you whether the compiler is at
fault, or the value programmed at 3FFh is wrong.

Actually, before you do this look at the instruction in 3FFh and verify
that it is in fact a RETLW.  If not something got corrupted or Microchip
screwed up.  Start with a brand new virgin chip and look at the
instruction at 3FFh.  This should be a RETLW, so write down its value.
Then try the assembler program.  You could even hard code the value you
wrote down into the assembler program instead of trying to call 3FFh.
After the assembler program is loaded into the chip, verify that the
proper RETLW is still at 3FFh.  If not, then your programmer is the
culprit because it doesn't save that location before a bulk erase and
restore it afterwards.  Either was, run the program and see what you get.

The other intersting thing to do would be to single step thru the compiled
code in the program memory window.  Even if everything is working, it
might be useful to know what the compiler is doing on startup.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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

2003\02\19@112414 by llile

flavicon
face
Right now I am going on the theory that this is a HITECH compiler issue. I
find that the OSCCAL number is overwritten in program memory after I
program my parts with the HITECH compiler and a PICstart.  I am really
confused by the format of the Hitech listing file, so I am not really sure
what I am looking at.



-- Lawrence Lile





.....llileKILLspamspam.....SALTONUSA.COM
Sent by: pic microcontroller discussion list <EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU>
02/18/2003 05:31 PM
Please respond to pic microcontroller discussion list


       To:     PICLISTspamspam_OUTMITVMA.MIT.EDU
       cc:
       Subject:        [PIC]:  Up is not UP, Down is not Down, and  OSCCAL is not CAL'd


I am seeing an interesting problem with the OSCCAL and internal RC
oscillator in a 16F676.  The spec sheet sez that the tolerance on the
internal RC oscillator is +/- 2%, under most any conceivable operating
voltage and temperature.   Compiling under Hitech C.  Operating at 5.0
volts DC at 24degrees C ambient.

I am using parts that are "supposed" to have been programmed with the
correct OSSCAL number.

I consistently measure the oscillator as running about 20-26% too slow in
five consecutive parts.  I measured them several ways, 1. by using a 60
seconds interval based on a  timer1 timeout and a stopwatch ,    2. by
using a series of bcf bsf bcf bsf  statements to toggle a pin, and      3.
by using a loop

do{
       bit_clear(PORTA, 2)
       nop();
       nop();
       bit_set(PORTA,2);
       While(1);

which generates a continuous stream of pulses 6 clocks long (3 up, 3
down).  I find that 6 clocks takes 7.6 uS, about 26% too long.  (note -
bit-clear, bit_set and nop are not defined in HITECH C, but I define them
to do what they say they do)  all these measurements come out 20-26% too
slow.

Now, HITECH C Claims it automatically takes care of the OSSCAL register on
startup.  This is interesting, but I cannot verify it in the listing file,
not being able to locate the applicable code, nor even the powerup psect.

I can think of three causes for unCAL'd OSSCALs:

1. HITECH C ignores the OSCCAL register, contrary to what it says on pg
134 of the manual,

2. MCHIP's calibration is no good, contrary to what it says in the 16F676
datasheet,

3.  I have somehow managed to flub up this measurement despite having
checked it three different ways,

4. My brand new HP scope, just back from factory calibration, is out of
calibration, and my stopwatch is out of calibration by the same amount,
despite having been calibrated against the atomic clock less than 6 months
ago

5. The '676, being a brand new part, has a major silicon bug

6. There is something else going on that is very wierd.


Now, none of these causes seems very likely to me.  Can anyone suggest a
cause that could be more likely?

--Lawrence




--
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 @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

2003\02\19@113405 by Spehro Pefhany

picon face
At 10:23 AM 2/19/2003 -0600, you wrote:
>Right now I am going on the theory that this is a HITECH compiler issue. I
>find that the OSCCAL number is overwritten in program memory after I
>program my parts with the HITECH compiler and a PICstart.  I am really
>confused by the format of the Hitech listing file, so I am not really sure
>what I am looking at.

Please let us know when you find out. I noticed the same problem, however
didn't care (much) as I don't need the oscillator calibrated.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
KILLspamspeffKILLspamspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

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

2003\02\19@114140 by llile

flavicon
face
Olin wrote:


>Actually, before you do this look at the instruction in 3FFh and verify
that it is in fact a RETLW.  If not something got corrupted or Microchip
screwed up.  Start with a brand new virgin chip and look at the
instruction at 0x3FFh.

I was able to take a new chip and verify that Microchip's PICSTART leaves
this value in place when erasing and programming, but after programming
with the output of the Hitech compiler the 0x3FF value has changed. Looks
a lot like a HITECH compiler issue to me, that was the item I least
expected on my list!

>The other intersting thing to do would be to single step thru the
compiled
code in the program memory window.  Even if everything is working, it
might be useful to know what the compiler is doing on startup.

Now here comes another issue with Hitech compiler - Single Stepping would
be really nice if it actually worked.  When I single step through my
program under MPLAB, The first 20-30 instructions are invisible.  There is
no indication where these instruction fall in the listing file nor the C
source. THere is no highlight bar showing what instruction is being
executed.  After the initial blindness, things seem to work normally, the
cursor bar in the listing file seems to have some relationship to code
being executed.  OTOH, the cursor bar in the listing file will also land
on comments, blank lines, psect statements, and other garbage making it
useless in following program execution.  THis is all under MPLAB 5.7.40.
Under MPLAB 6.x, simulation is even crazier so I dumped it until they get
it out of beta test.

And to think I bought the Hitech compiler to get away from bugs!



-- Lawrence Lile



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

2003\02\19@115410 by Alan B. Pearce

face picon face
>Now here comes another issue with Hitech compiler - Single Stepping
>would be really nice if it actually worked.  When I single step
>through my program under MPLAB, The first 20-30 instructions are
>invisible.  There is no indication where these instruction fall in
>the listing file nor the C source. THere is no highlight bar showing
>what instruction is being executed.

This sounds like start up code provided with the compiler, and they do not
provide the source to the linked module. I wonder what the program memory
window shows while this is happening.

>After the initial blindness, things seem to work normally, the cursor
>bar in the listing file seems to have some relationship to code being
>executed.  OTOH, the cursor bar in the listing file will also land on
>comments, blank lines, psect statements, and other garbage making it
>useless in following program execution.  THis is all under MPLAB 5.7.40.

This seems to be normal under MPLAB 5.x. It does the same when stepping
through assembler macros, so what you see is actually an MPLAB issue here I
believe. I do not recall this happening with earlier versions of MPLAB, but
then I never got serious with using it. But then you would have thought this
sort of issue would have been sorted long ago. I have noticed that each
update to MPLAB seems to introduce a new set of bugs that have not been an
issue before, so someone seems to muck around with code that should not need
touching.

>And to think I bought the Hitech compiler to get away from bugs!
<grin>

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

2003\02\19@120227 by Olin Lathrop

face picon face
> Right now I am going on the theory that this is a HITECH compiler issue.
I
> find that the OSCCAL number is overwritten in program memory after I
> program my parts with the HITECH compiler and a PICstart.  I am really
> confused by the format of the Hitech listing file, so I am not really
sure
> what I am looking at.

So screw the listing and look at the resulting opcodes instead.  If it
sets OSCCAL at all, it's going to do it pretty soon after reset.  It would
probably be quite illuminating to single step thru the individual
instructions from reset in the program memory window.  You might see a few
other things it's doing you didn't expect.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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

2003\02\19@120842 by Olin Lathrop

face picon face
> I was able to take a new chip and verify that Microchip's PICSTART
leaves
> this value in place when erasing and programming, but after programming
> with the output of the Hitech compiler the 0x3FF value has changed.
Looks
> a lot like a HITECH compiler issue to me, that was the item I least
> expected on my list!

Did you make sure no real code can be placed at 3FFh.  The easiest way to
do this is to set up the linker sections so that 3FFh doesn't exist, or at
least is in a separate section flagged as PROTECTED.  A look at the link
map should tell you if anything got placed there.

> Now here comes another issue with Hitech compiler - Single Stepping
would
> be really nice if it actually worked.  When I single step through my
> program under MPLAB, The first 20-30 instructions are invisible.

That's why I keep saying to single step **in the program memory window**,
not in the source code.  That will (should) show you each instruction
regardless of where it came from.  I've never used MPLAB with a compiler,
but I would be very surprised if the program memory window goes away in
that case, or the ability to single step in that window.  Worst case,
create a new MPLAB project and tell it you are only using the assembler,
then import the raw HEX file.  That will definitely allow you to single
step each instruction.  Since there isn't any source code the startup code
came from directly, lack of a source window won't matter here.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, 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

2003\02\19@142341 by Rob Hamerling

flavicon
face
llile@SALTONUSA.COM wrote:

> I was able to take a new chip and verify that Microchip's PICSTART leaves
> this value in place when erasing and programming, but after programming
> with the output of the Hitech compiler the 0x3FF value has changed. Looks
> a lot like a HITECH compiler issue to me

It seems very unlikely to me that a PIC program will occupy the very
last word of program memory! But your compiler might insert code to
blank program memory beyond the areas it occupies itself.
I'm using CC5X, which doesn't do so and leaves the last word of program
memory untouched, but it doesn't calibrate OSCCAL by itself.

Regards, Rob.

--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

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

2003\02\19@150241 by Brent Brown

picon face
llile@SALTONUSA.COM wrote:
> I was able to take a new chip and verify that Microchip's PICSTART
> leaves this value in place when erasing and programming, but after
> programming with the output of the Hitech compiler the 0x3FF value has
> changed. Looks a lot like a HITECH compiler issue to me

Which header file is the compiler using for the PIC16F676? I am
curious because I can't find one for it in v8.01 PL3. There is a line
in pic.h that tells it to use pic16630.h for both the PIC16F630 and
PIC16F676, but that file does not appear in my include directory. A
long shot, but this could be a problem. If there is a compiler
problem Hi-Tech should be able to get it sorted for you.

--
Brent Brown, Electronic Design Solutions
16 English Street, Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/txt: 025 334 069
eMail:  RemoveMEbrent.brownEraseMEspamEraseMEclear.net.nz

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

2003\02\19@151105 by Spehro Pefhany

picon face
At 10:40 AM 2/19/2003 -0600, you wrote:

>I was able to take a new chip and verify that Microchip's PICSTART leaves
>this value in place when erasing and programming, but after programming
>with the output of the Hitech compiler the 0x3FF value has changed. Looks
>a lot like a HITECH compiler issue to me, that was the item I least
>expected on my list!

Lawrence, if you look in the lib subdirectory, there should be a file
named picinfo.ini. It should have a section something like the below:

[16F676]
ARCH=PIC14
ROMSIZE=3FF
BANKS=2
RAMBANK=20,7F
COMMON=20,7F
ZEROREG=9
#PRINTF=ILF

What happens if you change it to: ROMSIZE=3FE ?

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
RemoveMEspeffTakeThisOuTspamspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

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

2003\02\19@191425 by llile

flavicon
face
Olin sez:

> Now here comes another issue with Hitech compiler - Single Stepping
would
> be really nice if it actually worked.  When I single step through my
> program under MPLAB, The first 20-30 instructions are invisible.

>That's why I keep saying to single step **in the program memory window**,
not in the source code.  That will (should) show you each instruction
regardless of where it came from.

Aha! I am beginning to smell a rat.   In MPLAB 5.70.40, the program memory
window is useless! This sounds like an MPLAB issue to me.  It does not
display opcodes, it just displays a hex dump of program memory.  Opcodes
are not really distinguishable.  Also there is no cursor in the program
memory window showing you where you are, just a big hex dump of memory.
Olin, we are seeing completely different things in the program memory
window.

Oh, why did I ever uninstall the old, stable version of MPLAB??  This is
why I haven't been able to see the first few instructions while single
stepping, there is no longer a program memory window that has any meaning
in the simulator.

We are probably on different versions of MPLAB, with completely different
functionality in the program memory window.  Or at least, it behaves
differently with a compiler than with assembler.




-- Lawrence Lile
Senior Project Engineer
Toastmaster, Inc.
Division of Salton, Inc.
573-446-5661 voice
573-446-5676 fax




Olin Lathrop <RemoveMEolin_piclistKILLspamspamEMBEDINC.COM>
Sent by: pic microcontroller discussion list <PICLISTSTOPspamspamspam_OUTMITVMA.MIT.EDU>
02/19/2003 11:07 AM
Please respond to pic microcontroller discussion list


       To:     spamBeGonePICLISTSTOPspamspamEraseMEMITVMA.MIT.EDU
       cc:
       Subject:        Re: [PIC]:  Up is not UP, Down is not Down, and  OSCCAL is not CAL'd


> I was able to take a new chip and verify that Microchip's PICSTART
leaves
> this value in place when erasing and programming, but after programming
> with the output of the Hitech compiler the 0x3FF value has changed.
Looks
> a lot like a HITECH compiler issue to me, that was the item I least
> expected on my list!

Did you make sure no real code can be placed at 3FFh.  The easiest way to
do this is to set up the linker sections so that 3FFh doesn't exist, or at
least is in a separate section flagged as PROTECTED.  A look at the link
map should tell you if anything got placed there.

> Now here comes another issue with Hitech compiler - Single Stepping
would
> be really nice if it actually worked.  When I single step through my
> program under MPLAB, The first 20-30 instructions are invisible.

That's why I keep saying to single step **in the program memory window**,
not in the source code.  That will (should) show you each instruction
regardless of where it came from.  I've never used MPLAB with a compiler,
but I would be very surprised if the program memory window goes away in
that case, or the ability to single step in that window.  Worst case,
create a new MPLAB project and tell it you are only using the assembler,
then import the raw HEX file.  That will definitely allow you to single
step each instruction.  Since there isn't any source code the startup code
came from directly, lack of a source window won't matter here.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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



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

2003\02\19@191623 by llile

flavicon
face
Slick!  I'll try this tomorrow.

-- Lawrence Lile





Spehro Pefhany <@spam@speff@spam@spamspam_OUTINTERLOG.COM>
Sent by: pic microcontroller discussion list <spamBeGonePICLISTspamKILLspamMITVMA.MIT.EDU>
02/19/2003 02:09 PM
Please respond to pic microcontroller discussion list


       To:     .....PICLISTspam_OUTspamMITVMA.MIT.EDU
       cc:
       Subject:        Re: [PIC]:  Up is not UP, Down is not Down, and  OSCCAL is not CAL'd


At 10:40 AM 2/19/2003 -0600, you wrote:

>I was able to take a new chip and verify that Microchip's PICSTART leaves
>this value in place when erasing and programming, but after programming
>with the output of the Hitech compiler the 0x3FF value has changed. Looks
>a lot like a HITECH compiler issue to me, that was the item I least
>expected on my list!

Lawrence, if you look in the lib subdirectory, there should be a file
named picinfo.ini. It should have a section something like the below:

[16F676]
ARCH=PIC14
ROMSIZE=3FF
BANKS=2
RAMBANK=20,7F
COMMON=20,7F
ZEROREG=9
#PRINTF=ILF

What happens if you change it to: ROMSIZE=3FE ?

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the
reward"
TakeThisOuTspeff.....spamTakeThisOuTinterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

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



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

2003\02\19@191635 by llile

flavicon
face
I think I remember upgrading, or getting a header file special from Hitech
one or the other.  Yes it is the pic16630.h file.


-- Lawrence Lile





Brent Brown <RemoveMEbrent.brownspamspamBeGoneCLEAR.NET.NZ>
Sent by: pic microcontroller discussion list <spamBeGonePICLIST@spam@spamspam_OUTMITVMA.MIT.EDU>
02/19/2003 01:56 PM
Please respond to pic microcontroller discussion list


       To:     TakeThisOuTPICLISTspamspamMITVMA.MIT.EDU
       cc:
       Subject:        Re: [PIC]:  Up is not UP, Down is not Down, and  OSCCAL is not CAL'd


llileEraseMEspamSALTONUSA.COM wrote:
> I was able to take a new chip and verify that Microchip's PICSTART
> leaves this value in place when erasing and programming, but after
> programming with the output of the Hitech compiler the 0x3FF value has
> changed. Looks a lot like a HITECH compiler issue to me

Which header file is the compiler using for the PIC16F676? I am
curious because I can't find one for it in v8.01 PL3. There is a line
in pic.h that tells it to use pic16630.h for both the PIC16F630 and
PIC16F676, but that file does not appear in my include directory. A
long shot, but this could be a problem. If there is a compiler
problem Hi-Tech should be able to get it sorted for you.

--
Brent Brown, Electronic Design Solutions
16 English Street, Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/txt: 025 334 069
eMail:  RemoveMEbrent.brownEraseMEspamspam_OUTclear.net.nz

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



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

2003\02\20@042545 by Alan B. Pearce

face picon face
>Aha! I am beginning to smell a rat.   In MPLAB 5.70.40, the
>program memory window is useless! This sounds like an MPLAB
>issue to me.  It does not display opcodes, it just displays
>a hex dump of program memory.  Opcodes are not really
>distinguishable.

Huh???? I just loaded the hex file that is used to update the ICE-1, and it
certainly shows me opcodes. Now the bit and registers names are not known,
so these are shown as hex numbers, but the mnemonic is certainly there.

>Also there is no cursor in the program memory window showing
>you where you are, just a big hex dump of memory. Olin, we are
>seeing completely different things in the program memory window.

Huh again ??? In mine I have a big black inverse video bar at the next line
of code to be executed.

>Oh, why did I ever uninstall the old, stable version of MPLAB??
>This is why I haven't been able to see the first few instructions
>while single stepping, there is no longer a program memory window
>that has any meaning in the simulator.

You mean you did not keep the previous version ZIP file ?? I am running
5.6.0 to get the above results. I gave up on 5.6.1 and went back because of
some other issues as I recall. I never got 5.7 because I did not need the
processor upgrade path, which is why I assume you are using it.

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestspam_OUTspam.....mitvma.mit.edu>

2003\02\20@061748 by Nigel Orr

flavicon
face
Alan Pearce wrote on Thursday, February 20, 2003 9:26 AM:

>> Aha! I am beginning to smell a rat.   In MPLAB 5.70.40, the
>> program memory window is useless! This sounds like an MPLAB
>> issue to me.  It does not display opcodes, it just displays
>> a hex dump of program memory.
>
> Huh???? I just loaded the hex file that is used to update the ICE-1,
> and it certainly shows me opcodes. Now the bit and registers names

There are 2 different "program memory" windows in all the recent versions
of MPLAB which I have used.  One is what Alan has just described, one is
what Lawrence has described.

ISTR that Alan's one (the useful one!) appears when you have set up a
project including your hex file, Lawrence's (not-very-useful-at-all-one!)
appears if you import a hex file from the File menu.  Unfortunately, I
don't have MPLAB in front of me at the moment to check, and it's a few
weeks since I last had the same problem.

Nigel
--
Nigel Orr, Design Engineer                 spamBeGonenigelEraseMEspamaxoninstruments.co.uk
Axon Instruments Ltd., Wardes Road,Inverurie,Aberdeenshire,UK,AB51 3TT
              Tel:+44 1467 622332 Fax:+44 1467 625235
                  http://www.axoninstruments.co.uk

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

2003\02\20@064650 by hael Rigby-Jones

picon face
> -----Original Message-----
> From: RemoveMEllile@spam@spamspamBeGoneSALTONUSA.COM [SMTP:.....llile@spam@spamEraseMESALTONUSA.COM]
> Sent: Thursday, February 20, 2003 12:14 AM
> To:   .....PICLISTRemoveMEspamMITVMA.MIT.EDU
> Subject:      Re: [PIC]:  Up is not UP, Down is not Down, and  OSCCAL is
> not CAL'd
>
> Aha! I am beginning to smell a rat.   In MPLAB 5.70.40, the program memory
> window is useless!
>
Better check the user before blaming the software :o)

Simply click on the control menu (top left hand corner) and a popup menu
will let you display Hex code/Machine code/Dissasembly.  You have it set to
Hex Code at the moment.

Regards

Mike

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestSTOPspamspam@spam@mitvma.mit.edu>

2003\02\20@080508 by Olin Lathrop

face picon face
> Aha! I am beginning to smell a rat.   In MPLAB 5.70.40, the program
memory
> window is useless!

That's exactly the same version I am using, and the program memory window
is very useful.  Of course I didn't mess it up by installing a complier
into it <g>.

> This sounds like an MPLAB issue to me.  It does not
> display opcodes, it just displays a hex dump of program memory.

No, you just don't have the mode set right.  The program memory window has
three modes.  You have it set to "hex code display".  The other two are
"machine code display" and "disassembly display".  Select either of the
two others, then do an F6 (reset), and you will see a bar thru location 0
indicating where the program counter is pointing.  Keep the focus on the
program memory window and keep hitting F7 (step into), and you will see
each instruction executed one at a time.  The source code window will be
useless during this process because it won't know what source line to
associate with each instruction.

I usually keep my program memory window in "machine code display" mode.
The disassembler isn't as smart as it thinks it is, and usually picks the
wrong symbol to display when multiple symbols happen to have the same
value.  This is more misleading than just seeing HEX target addresses.
Usually I'm single stepping in the program memory window while having it
track the source code in the source window as best it can.

> Oh, why did I ever uninstall the old, stable version of MPLAB??

I find 5.70.40 is pretty good.  It has all the same stupid things wrong
with it that MPLAB has had for years, but it otherwise seems solid.  A
serious linker bug from a few months ago has been fixed.

> Or at least, it behaves differently with a compiler than with assembler.

That is still possible, but probably not.

Are you willing to send me your HEX file?  I don't need anything else to
step thru your program other than knowing what processor it was built for.
I'm actually a bit curious what the compiler does behind your back for the
first few instructions.  You can send it to me privately if you don't want
to broadcast it to the list.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestEraseMEspam@spam@mitvma.mit.edu>

2003\02\20@121623 by llile

flavicon
face
Moments ago, HITECH support emailed me and told me to do this very same
thing.  You get the door prize, Sphero!


-- Lawrence Lile





Spehro Pefhany <RemoveMEspeffspamspamBeGoneINTERLOG.COM>
Sent by: pic microcontroller discussion list <spamBeGonePICLISTKILLspamspam@spam@MITVMA.MIT.EDU>
02/19/2003 02:09 PM
Please respond to pic microcontroller discussion list


       To:     PICLISTspam_OUTspam@spam@MITVMA.MIT.EDU
       cc:
       Subject:        Re: [PIC]:  Up is not UP, Down is not Down, and  OSCCAL is not CAL'd


At 10:40 AM 2/19/2003 -0600, you wrote:

>I was able to take a new chip and verify that Microchip's PICSTART leaves
>this value in place when erasing and programming, but after programming
>with the output of the Hitech compiler the 0x3FF value has changed. Looks
>a lot like a HITECH compiler issue to me, that was the item I least
>expected on my list!

Lawrence, if you look in the lib subdirectory, there should be a file
named picinfo.ini. It should have a section something like the below:

[16F676]
ARCH=PIC14
ROMSIZE=3FF
BANKS=2
RAMBANK=20,7F
COMMON=20,7F
ZEROREG=9
#PRINTF=ILF

What happens if you change it to: ROMSIZE=3FE ?

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the
reward"
spamBeGonespeff@spam@spaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

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



--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspam_OUTspamRemoveMEmitvma.mit.edu>

2003\02\20@123450 by ?iso-8859-1?Q?Per_Linn=E9?=

flavicon
face
I use MPLAB V5.70.0 and have none of the problems as
described. I have tried both "windows" right now and
both show all three modes. On the other hand I use
the CCS tools and have done so for the last 6 years.
Have not tried the 18xxx yet, so I can't tell about that.

PerL

{Original Message removed}

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