Programming 12F629 low power (Sleep)


Closed Thread
Results 1 to 18 of 18
  1. #1
    Warrier's Avatar
    Warrier Guest

    Default Programming 12F629 low power (Sleep)

    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?

  2. #2
    Join Date
    Sep 2004
    Location
    montreal, canada
    Posts
    6,898


    Did you find this post helpful? Yes | No

    Default

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

    Steve

    It's not a bug, it's a random feature.
    There's no problem, only learning opportunities.

  3. #3
    Join Date
    Sep 2004
    Location
    montreal, canada
    Posts
    6,898


    Did you find this post helpful? Yes | No

    Default

    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
    Steve

    It's not a bug, it's a random feature.
    There's no problem, only learning opportunities.

  4. #4
    Warrier's Avatar
    Warrier Guest


    Did you find this post helpful? Yes | No

    Default

    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.

  5. #5
    Warrier's Avatar
    Warrier Guest


    Did you find this post helpful? Yes | No

    Default

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

  6. #6
    Join Date
    Sep 2004
    Location
    montreal, canada
    Posts
    6,898


    Did you find this post helpful? Yes | No

    Default

    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???
    Last edited by mister_e; - 25th November 2004 at 22:06.
    Steve

    It's not a bug, it's a random feature.
    There's no problem, only learning opportunities.

  7. #7
    Warrier's Avatar
    Warrier Guest


    Did you find this post helpful? Yes | No

    Default

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

  8. #8
    kattronics's Avatar
    kattronics Guest


    Did you find this post helpful? Yes | No

    Default

    Just a thought, did you loose the "factory" osc calabration?

  9. #9
    Join Date
    May 2004
    Location
    New England
    Posts
    164


    Did you find this post helpful? Yes | No

    Default

    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

  10. #10
    Warrier's Avatar
    Warrier Guest


    Did you find this post helpful? Yes | No

    Default

    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

  11. #11
    kattronics's Avatar
    kattronics Guest


    Did you find this post helpful? Yes | No

    Default

    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?

  12. #12
    Warrier's Avatar
    Warrier Guest


    Did you find this post helpful? Yes | No

    Default

    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

  13. #13
    Join Date
    May 2004
    Location
    New England
    Posts
    164


    Did you find this post helpful? Yes | No

    Default

    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

  14. #14
    Warrier's Avatar
    Warrier Guest


    Did you find this post helpful? Yes | No

    Default

    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

  15. #15
    Join Date
    May 2004
    Location
    New England
    Posts
    164


    Did you find this post helpful? Yes | No

    Default

    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?

  16. #16
    Warrier's Avatar
    Warrier Guest


    Did you find this post helpful? Yes | No

    Default

    Hi Arch:

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

  17. #17
    Join Date
    May 2004
    Location
    New England
    Posts
    164


    Did you find this post helpful? Yes | No

    Default

    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

  18. #18
    Keith55555's Avatar
    Keith55555 Guest


    Did you find this post helpful? Yes | No

    Default

    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.

Similar Threads

  1. Battery powered applications
    By NavMicroSystems in forum Off Topic
    Replies: 7
    Last Post: - 22nd June 2009, 07:12
  2. Old and beyond help ?
    By DavidFMarks in forum mel PIC BASIC Pro
    Replies: 46
    Last Post: - 11th December 2008, 15:23
  3. Using Sleep
    By elec_mech in forum mel PIC BASIC Pro
    Replies: 2
    Last Post: - 17th August 2008, 04:05
  4. 12F629 Strange interupt behavior
    By BGreen in forum mel PIC BASIC Pro
    Replies: 8
    Last Post: - 25th May 2007, 15:35
  5. 4-line LCD Help - using PortA instead of B
    By Tom Gonser in forum mel PIC BASIC Pro
    Replies: 28
    Last Post: - 31st March 2005, 03:14

Members who have read this thread : 2

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts