PDA

View Full Version : Programming 12F629 low power (Sleep)



Warrier
- 25th November 2004, 19:32
Programming 12F629 with PICALL causes a strange problem.. if the code contains any NAP or Sleep the device becomes useless after the first time -even during first time the configuration part reports error. I can erase it and read it but cannot program at all. The device blank checks OK!

What am I doing wrong? Any suggestion?

mister_e
- 25th November 2004, 19:41
this is strange... nothing happen when there's no SLEEP or NAP in code???

what about if you try to blank it before programming ?

oups already said... may you try to short to ground LVP pin and place an 0.1 uF between VDD & VSS ???

mister_e
- 25th November 2004, 19:55
12f series offers some Micro-power feature... be sure there's no voltage on i/o while sleeping.

pure guess here. If your PIC is under SLEEP mode, what about if you reset it ???

I don't know PICALL but is there any minimum voltage and maximum voltage check??? if there's can you by any setting cancel these tests?

regards

Warrier
- 25th November 2004, 21:21
Hi Steve:

Here is the of code:

main:
manual=0
xmt=1
PauseUs 12
IF GPIO.2=0 Then
manual=1
Pause 1000
manual=0
Else
manual=0
EndIF
PauseUs 24
xmt=0
NAP 3
GoTo main

it's part of a cheap touch sensitive switch!

if I replace the NAP3 with Pause 150 I can reprogram the chip any number of times. But using the NAP 3 the device reports the following error:
Program: address: 0000 buffer=2837 device=3FFF

And that's it. It acts like an OTP. The chip works ok though but can't reprogram!

I always erase even new devices before programming. I use Internal RC osc.

I mentioned PICALL just in case it's the programmer causing it. It's connected to the serial port & I checked the communication speed and its ok.

I've lost too many 629's and am stumped.

Warrier
- 25th November 2004, 21:25
Steve

I forgot to mention. It goes bad while programming only..
No PWR UP Tmr, MCLR is off, WDT is on for NAP mode, Brown out is off to pick up a few uA while running... But these may not be real issues.

Also there are a few occasions when they do come throu ok. Also OK if the code length is near 1k!!!!

mister_e
- 25th November 2004, 22:03
that's really weird warrier.

What about if you set
Power up timer ON
Brown out detect On

i'm about thinking it's an programmer problem but REALLY NOT SURE OF IT.

Maybe somebody else have some explanation for this... What PICALL provider says about that???

Warrier
- 25th November 2004, 22:25
I've tried all combinations available with configuration. It happens only if I have a NAP or SLEEP command!!! The PICALL programmer works fine with 16F628, 16F676 etc. I need an 8pin device hence the 12F629.

It also bothers me that if the code exceeds about 400bytes or so, it seems to do ok. I'm going to put in some dummy code to fill up space and try gain. I have also tried end point of the program to other than 3FFF -no help. So I am not sure filling the program area would help.

Anyone else out there who has faced this problem???

kattronics
- 26th November 2004, 00:59
Just a thought, did you loose the "factory" osc calabration?

Archilochus
- 26th November 2004, 01:22
Just curious - when you read back one of the 'bad' programmed '629s, is the configuration word the same as what you originally programmed in?

If not - in what way{s} is it different?

Arch

Warrier
- 26th November 2004, 03:28
guys:

Yes to both of you--I lost the calibration and the configuration goes from

InRC - NO_CLKOUT
to
ER ; CLKOUT ; BOD_ON!

do these mean anything to either of you?

warrier

kattronics
- 26th November 2004, 13:33
Since you lost the calabration. Go ahead and add something before you program the chip. I have 2 chips that have "347c" for the factory calabration.

Someware I seen that you can add oscal = $80 in your code for a midpoint

Also are you verifying the fuses at programming time?

Warrier
- 26th November 2004, 13:58
I also have a few with calibration ranging from 34A0 to 347C..
I will try including the oscal line in my code...

I cleared the buffer (3FFF) and disabled writing the config.. The bad chips run through and completes successfully! With any other value in data or program field it stops. Also it stops if config value is enabled... produces verify error buffer=318C device=3FFF

Archilochus
- 26th November 2004, 16:35
Hi Warrier,
Not sure what's going on - but it sounds very similar to what was happening to me just the other day.

Using Picall version 0.15a...

Was trying to program a 16F628, and the thing was doing all sorts of wild stuff after programming (or not working at all).

Would read back the CONFIG word with ER ; CLKOUT ; BOD_ON - even though I had not programmed it that way.

Turns out I had accidentally 'un-checked' the selection box for "Write Config./Prot.
So no matter what I set with DEFINES in the program, or entered in the Picall 'EDIT' - 'Configuration' menu - I'd end up with the same wrong CONFIG word being programmed.
Also would get assorted error messages.

Don't know if it's the same problem with yours - but very similar results!

Arch

Warrier
- 26th November 2004, 16:45
Hi Arch:

Appreciate you sharing your similar problem with PICALL and F628. But No Sir, I had my config checked and playing with about 10 of these '629 I ended up with 3 good ones that I could program again! I 'm an old geiser who can't afford loosing my coffee funds on these "chips" -sorry for the pun.

You see they program ok if I don't use NAP or SLEEP ..

Thanks anyway...

warrier

Archilochus
- 26th November 2004, 19:48
Seems like a silly one - but err... well... I've done it couple times...

Is the right 'device' selected in Picall's drop down menu?

Warrier
- 26th November 2004, 20:10
Hi Arch:

Yes of course... I have checked thru all the settings but this thing still stings!

Archilochus
- 28th November 2004, 18:15
Hi Warrier,
I'd sure like to hear about the solution if / when you get it figured out. I was thinking of trying a couple projects with the '629 - and I have the Picall programmer too.
I might try sacrificing a few '629s and see if the same errors happen.

Arch

Keith55555
- 29th November 2004, 14:45
Hi although I'm pretty sure this same problem has a different source than mine,it might be good for me to describe what happened to me with the same results/problems.I assume you are using the internal osc in the 'f629 so this is probably not applicable but I was running one with a HF xtal and I couldn't get it to program a second time.Realized once programmed,the thing was beating out the programmer and changing pin assignments that are used for the clock and data lines(this of course was ICSP).I wound up doing a 'see who wins' race by powering on right after I clicked 'program'.And voila(doesn't work every race but eventually...)Thought maybe this might help someone else that does a search for this problem.