Searching \ for ' 12CE674-JW odd behavior?' 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=12ce674+odd+behavior
Search entire site for: '12CE674-JW odd behavior?'.

No exact or substring matches. trying for part
PICList Thread
'[PICLIST] 12CE674-JW odd behavior?'
2001\06\01@130842 by Dale Botkin

flavicon
face
Hi all,

Last night I spent several hours wondering why a new project wouldn't work
most of the time.  I was using a 12CE674-JW part, and could NOT get it to
run reliably -- maybe one in 20 tries it would start.  I was using
internal RC osc, no CLR, power-up timer, with or without watchdog (didn't
seem to matter).  I finally stripped it down to a blink-the-LED stage,
still didn't work.  So I tried it with XT, 4MHz xtal, MCLR tied high.  It
worked, but only after I momentarily grounded MCLR.  No other code changes
were mde, the original version worked OK as long as I used MCLR and XT or
HS -- but of course I lost half the I/O pins doing that!

I am assuming it's not usually this bad to get something going using
internal RC and no MCLR int eh 8-pin package.  I did think of the exposed
chip and tried it several times with the window covered (by my thumb),
which seemd to make no differene at all.  I looked in teh data sheet to
see if I could spot any -JW specific quirks and didn't see any...  anyone
have any bright ideas, something I missed? This is the first time I've
tried using internal RC and no MCLR, needless to say the results were not
encouraging.  I have to assume it was something I did wrong...

Dale
--
A train stops at a train station.  A bus stops at a bus station.
On my desk I have a workstation...

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


2001\06\01@132336 by Mark Bishop

flavicon
face
I added a delay routine on power-up and it cleared things up.

Just my .02

-----Original Message-----
From: Dale Botkin [spam_OUTdaleTakeThisOuTspamBOTKIN.ORG]
Sent: Friday, June 01, 2001 1:11 PM
To: .....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU
Subject: 12CE674-JW odd behavior?


Hi all,

Last night I spent several hours wondering why a new project wouldn't work
most of the time.  I was using a 12CE674-JW part, and could NOT get it to
run reliably -- maybe one in 20 tries it would start.  I was using
internal RC osc, no CLR, power-up timer, with or without watchdog (didn't
seem to matter).  I finally stripped it down to a blink-the-LED stage,
still didn't work.  So I tried it with XT, 4MHz xtal, MCLR tied high.  It
worked, but only after I momentarily grounded MCLR.  No other code changes
were mde, the original version worked OK as long as I used MCLR and XT or
HS -- but of course I lost half the I/O pins doing that!

I am assuming it's not usually this bad to get something going using
internal RC and no MCLR int eh 8-pin package.  I did think of the exposed
chip and tried it several times with the window covered (by my thumb),
which seemd to make no differene at all.  I looked in teh data sheet to
see if I could spot any -JW specific quirks and didn't see any...  anyone
have any bright ideas, something I missed? This is the first time I've
tried using internal RC and no MCLR, needless to say the results were not
encouraging.  I have to assume it was something I did wrong...

Dale
--
A train stops at a train station.  A bus stops at a bus station.
On my desk I have a workstation...

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

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


2001\06\01@133227 by Dan Michaels

flavicon
face
Dale Botkin wrote:

>Last night I spent several hours wondering why a new project wouldn't work
>most of the time.  I was using a 12CE674-JW part, and could NOT get it to
>run reliably -- maybe one in 20 tries it would start.

>I am assuming it's not usually this bad to get something going using
>internal RC and no MCLR int eh 8-pin package.  I did think of the exposed
>chip and tried it several times with the window covered (by my thumb),
>which seemd to make no differene at all.  I looked in teh data sheet to
>see if I could spot any -JW specific quirks and didn't see any...  anyone
>have any bright ideas, something I missed? This is the first time I've
>tried using internal RC and no MCLR, needless to say the results were not
>encouraging.  I have to assume it was something I did wrong...
>


Dale, I have used the 12C672, but not CE parts, in that mode
many times, and had no problem. Maybe try programming with the
window "covered".

Also, I have found other Mchp JW parts a little quirkly regarding
how long to erase them, etc. Sometimes the programmer says they are
erased, but still they do not run properly after programming, even
though they would verify properly - so try at least once with a much
longer erasure period than you are using.

I have some errata notes regarding some of my previous experiences
with other JW parts - FYI:

http://www.oricomtech.com/piclinks.htm#Alert2

best regards,
- dan michaels
======================

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


2001\06\01@135042 by Quentin

flavicon
face
Dale Botkin wrote:
So I tried it with XT, 4MHz xtal, MCLR tied high.  It
> worked, but only after I momentarily grounded MCLR.
This tells me it could be a serious PSU problem. Not a stable startup.

> I am assuming it's not usually this bad to get something going using
> internal RC and no MCLR int eh 8-pin package.  This is the first time I've
> tried using internal RC and no MCLR, needless to say the results were not
> encouraging.  I have to assume it was something I did wrong...
Dale, are you using MPLAB? If you are using __CONFIG to set up things,
make sure you setup Development Mode in MPLAB to reflect your settings.
Look at the MCLR setting under pins. Been a while since I've used the
12Cxxx, but I remember something that MCLR must be set here rather than
__CONFIG (I could be wrong).

And two things I have to point out (even if you might know it already).
12Cxxx _JW: You did take note of the OSCI value before erasing and are
you setting the OSCI value everytime before you program?
WDT off?

Quentin

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


2001\06\01@140936 by Dale Botkin

flavicon
face
On Fri, 1 Jun 2001, Quentin wrote:

> Dale Botkin wrote:
>  So I tried it with XT, 4MHz xtal, MCLR tied high.  It
> > worked, but only after I momentarily grounded MCLR.
> This tells me it could be a serious PSU problem. Not a stable startup.

Nope...  Fresh 9V battery, 78L05, and a 16F876 co-resident on the same
board works perfectly.

> > I am assuming it's not usually this bad to get something going using
> > internal RC and no MCLR int eh 8-pin package.  This is the first time I've
> > tried using internal RC and no MCLR, needless to say the results were not
> > encouraging.  I have to assume it was something I did wrong...
>  Dale, are you using MPLAB? If you are using __CONFIG to set up things,
> make sure you setup Development Mode in MPLAB to reflect your settings.
> Look at the MCLR setting under pins. Been a while since I've used the
> 12Cxxx, but I remember something that MCLR must be set here rather than
> __CONFIG (I could be wrong).

Nope, the code is generated by CCS,and I checked the ASM listing and
config values.  It is getting set up the way I intended.

> And two things I have to point out (even if you might know it already).
> 12Cxxx _JW: You did take note of the OSCI value before erasing and are
> you setting the OSCI value everytime before you program?
> WDT off?

Yes, the osccal (0x3460 in this case) is getting saved and re-programmed.
I have tried it with and without WDT, no difference.  I'll try it again
with a longer erase cycle, and program it with the window covered.

Dale
--
A train stops at a train station.  A bus stops at a bus station.
On my desk I have a workstation...

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


2001\06\01@142520 by Karl Seibert

flavicon
face
Dale Botkin writes:

> > And two things I have to point out (even if you might know it already).
> > 12Cxxx _JW: You did take note of the OSCI value before erasing and are
> > you setting the OSCI value everytime before you program?
> > WDT off?
>
> Yes, the osccal (0x3460 in this case) is getting saved and re-programmed.
> I have tried it with and without WDT, no difference.  I'll try it again
> with a longer erase cycle, and program it with the window covered.
>
> Dale

Is 0x3460 the instruction at 0x7FF?  That translates to a RETLW 0x60.
The proper instruction is MOVWF 0x60 (0x3060).  You might be having
stack problems and jumping to the wrong place with the RETLW instruction
instead of just going to address 0.

Then again, I might not know what I'm talking about because I don't
have my PIC code here at work.

Karl

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


2001\06\01@144156 by Bob Ammerman

picon face
Power supply coming up too slow? Too noisy?

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

{Original Message removed}

2001\06\01@150816 by Dale Botkin

flavicon
face
On Fri, 1 Jun 2001, Karl Seibert wrote:

> Dale Botkin writes:
>
> > > And two things I have to point out (even if you might know it already).
> > > 12Cxxx _JW: You did take note of the OSCI value before erasing and are
> > > you setting the OSCI value everytime before you program?
> > > WDT off?
> >
> > Yes, the osccal (0x3460 in this case) is getting saved and re-programmed.
> > I have tried it with and without WDT, no difference.  I'll try it again
> > with a longer erase cycle, and program it with the window covered.
> >
> > Dale
>
> Is 0x3460 the instruction at 0x7FF?  That translates to a RETLW 0x60.
> The proper instruction is MOVWF 0x60 (0x3060).  You might be having
> stack problems and jumping to the wrong place with the RETLW instruction
> instead of just going to address 0.

Nope, data sheet says RETLW.

Dale
--
A train stops at a train station.  A bus stops at a bus station.
On my desk I have a workstation...

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


2001\06\01@151653 by Karl Seibert

flavicon
face
My original point about not knowing what I was talking
about because I didn't have my PIC code with me was
right.  :).  I was looking at the MOVWF OSCCAL and not
the RETLW xx  a few lines above in the data sheet.

Sorry about the wild goose chase.

Karl

Dale Botkin writes:

{Quote hidden}

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


2001\06\01@155655 by Dwayne Reid

flavicon
face
At 12:10 PM 6/1/01 -0500, Dale Botkin wrote:
>Hi all,
>
>Last night I spent several hours wondering why a new project wouldn't work
>most of the time.  I was using a 12CE674-JW part, and could NOT get it to
>run reliably -- maybe one in 20 tries it would start.  I was using
>internal RC osc, no CLR, power-up timer, with or without watchdog (didn't
>seem to matter).  I finally stripped it down to a blink-the-LED stage,
>still didn't work.  So I tried it with XT, 4MHz xtal, MCLR tied high.  It
>worked, but only after I momentarily grounded MCLR.

Check your power supply.  Try this: do the LED flash thingy but make it
active LO.  Connect the anode of the LED directly to the 5V supply,
resistor from LED to PIC pin.  Use a 100R resistor in series with the VDD
pin on the PIC, with a 100n cap from VDD to VSS.  Set all the other pins as
outputs and let them float.

Configure the PIC for internal RC, internal MCLR.  Apply power, see if it
works.  If it fails, ground the VDD pin on the PIC momentarily and see if
it works then.  Note: the 100R resistor limits the short circuit current.

I suspect you have one (or both) of two problems: rise time on VDD must be
monotonic and fairly fast (<10 msec from 0V to VDD) *and* VDD must be less
than 0.2Vdc when power is removed.  You WILL have problems if you allow VDD
to hover around 0.6 - 0.7 Vdc when power is turned off.

I have found that I have to pay strict attention to what kind of power
supply I feed the PIC with.  I have tried many approaches, ranging from a
simple 'hold the PIC in reset until after power is stable' (works every
time but you lose MCLR) to fairly simple 'remove power from the PIC until
the PSU is stable' type circuits (also works every time but costs parts).

I probably should gather all my approaches onto a single schematic and post
it somewhere.  Lack of time right now, though.

dwayne




Dwayne Reid   <dwaynerspamKILLspamplanet.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: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\06\01@160404 by ael E Maj ACC/XPPI

flavicon
face
If I am reading the datasheet correctly, a movwf OSCCAL instruction is still
required after a call to 0x7ff which will place the calibration value in w
(with the retlw 0xXX command which is at 0x7ff).

With the 12c509-JW you put a movlw 0xXX at 0x3ff and the movwf OSCCAL at
0x00.

The difference due to the fact the PC on reset is 0x3ff with the 509 vice
0x000 on the 674.

v/r Mike

{Original Message removed}

2001\06\01@161207 by Dale Botkin

flavicon
face
Dwayne, thanks for the advice.  I'm using a 9V battery with a 78L05
regulator, same as I have for dozens of prior projects.  On the same
board, powered the same way from the same bus, is a 16F876 with MCLR tied
directly to Vdd and the power-up timer enbled...  it works flawlessly, as
they all have.  Only this one chip has not reliably started, every time.
I'm trying to avoid having to use MCLR at all on this one, as I need that
pin for something else, so I was counting on the power-up timer to do the
reset.  It didn't appear to work.

It is possible that the 12CE674 is just more flaky during power up; I'll
try your shorted-Vdd approach tonight and see if that makes a difference.

Dale

On Fri, 1 Jun 2001, Dwayne Reid wrote:

{Quote hidden}

--
A train stops at a train station.  A bus stops at a bus station.
On my desk I have a workstation...

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


2001\06\01@170305 by Dwayne Reid

flavicon
face
At 03:58 PM 6/1/01 -0400, Evans Michael E Maj ACC/XPPI wrote:
>If I am reading the datasheet correctly, a movwf OSCCAL instruction is still
>required after a call to 0x7ff which will place the calibration value in w
>(with the retlw 0xXX command which is at 0x7ff).
>
>With the 12c509-JW you put a movlw 0xXX at 0x3ff and the movwf OSCCAL at
>0x00.
>
>The difference due to the fact the PC on reset is 0x3ff with the 509 vice
>0x000 on the 674.

Almost right: the 14 bit core parts use 'retlw XX' instead of 'movlw
XX'.  As you have noted, the 14 bit parts start execution at 0x00 instead
of top of memory.  You get the osc calibration constant by CALLing that
location somewhere within your code.

dwayne



Dwayne Reid   <EraseMEdwaynerspam_OUTspamTakeThisOuTplanet.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: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\06\02@050550 by Roman Black

flavicon
face
> >Last night I spent several hours wondering why a new project wouldn't work
> >most of the time.  I was using a 12CE674-JW part, and could NOT get it to
> >run reliably -- maybe one in 20 tries it would start.
>
> >I am assuming it's not usually this bad to get something going using
> >internal RC and no MCLR int eh 8-pin package.  I did think of the exposed
> >chip and tried it several times with the window covered (by my thumb),
> >which seemd to make no differene at all.  I looked in teh data sheet to
> >see if I could spot any -JW specific quirks and didn't see any...  anyone
> >have any bright ideas, something I missed? This is the first time I've
> >tried using internal RC and no MCLR, needless to say the results were not
> >encouraging.  I have to assume it was something I did wrong...


It sounds like a latchup problem. One specific difference
between the internal RC osc and XT mode is the RC modes
have no startup delay. The XT and HS modes have an automatic
1024 inst delay to allow crystal to stabilise before the
program starts executing. Remember your 5v rail can take
up to 500ms to get to proper value also.

If the input pins are floating during this critical start
up time they can latch up. My preference is to immediately
set the pins to outputs, allow about a 250ms delay in
software (maybe longer if you have more than 47uF after
the regulator) then switch them to ins/outs as needed
and start program operation. Never start a PIC up with
pins as inputs.
:o)
-Roman

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\06\02@090750 by michael brown

flavicon
face
Possibly something in the way the power supply ramps up?  Do you have the
PWRTE enabled?  Which oscillator XT or HS?  Maybe trying a different crystal
or bypass caps might help, maybe its not starting reliably.  Just some
things to think about from an uneducated fool. ;-)

Michael Brown
Instant Net Solutions
http://www.KillerPCs.net

{Original Message removed}

2001\06\02@122349 by Dale Botkin

flavicon
face
On Sat, 2 Jun 2001, michael brown wrote:

> Possibly something in the way the power supply ramps up?  Do you have the
> PWRTE enabled?  Which oscillator XT or HS?  Maybe trying a different crystal
> or bypass caps might help, maybe its not starting reliably.  Just some
> things to think about from an uneducated fool. ;-)

I did have PWRTE on.  With an external xtal, either HS or xt mode worked
fine as long as I grounded MCLR momentarily.  Using internal RC osc mode,
nothing worked.

I am beginning to think I may simply have a defective chip...  maybe the
power-up timer isn't working.

Dale
--
A train stops at a train station.  A bus stops at a bus station.
On my desk I have a workstation...

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\06\02@132039 by Alexandre Domingos F. Souza

flavicon
face
>the regulator) then switch them to ins/outs as needed
>and start program operation. Never start a PIC up with
>pins as inputs.

       Hmmm, great tip, goes to the "black book" :o)

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


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