Post by thread:[PICLIST] 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

I added a delay routine on power-up and it cleared things up. Just my .02 -----Original Message----- From: Dale Botkin [spam_OUTdaleTakeThisOuTBOTKIN.ORG] Sent: Friday, June 01, 2001 1:11 PM To: .....PICLISTKILLspam@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

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

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

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

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

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

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

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 <dwaynerKILLspamplanet.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

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}> 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 <.....dwaynerKILLspam.....planet.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 > > -- 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

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_OUTTakeThisOuTplanet.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

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

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