12F675 won't reprogram or erase


Closed Thread
Results 1 to 17 of 17
  1. #1
    Join Date
    Apr 2005
    Posts
    96

    Default 12F675 won't reprogram or erase

    These seems to have been discussed on here before, but I can't seem to figure out my problem.

    I've got a 12F675 setup and it will program a couple of times and now it doesn't program and won't erase. I'm using MELabs Serial Programmer and trying to set it up so that MCLR is an input and the internal osc is used. From my research this seems to be the combination that starts causing issues for other people. I'm guessing I erased the OSCAL Value and BadGap presets, but I'm not sure how to get them back.

    Since MCLR is set as an input I have a 5k pull-down resistor on it which is needed for my circuit. I'm not sure if that will cause an issue or not. My board is SMT so it is a little hard for me to modify, but I can try hooking MCLR to 5V through a diode to see if that helps.

    The config fuses seemed to work properly with the following:

    OSC = OSCINT
    POR = ON
    BOR = ON
    MCLR = Input Pin
    CP = ON
    CPD = ON

    I can read the dead circuit with the MELabs programmer, and all the fuses come back as above except OSC is set for LP.

    From my reading it sounds like I need to forget about using the MCLR pin as an input, but if I can help it I would rather not change my schematic and board design.

    I appreciate any input

    PS. Does anyone know how the MELabs programmer handles the OSCAL and BandGap presets on the 12F675?

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


    Did you find this post helpful? Yes | No

    Default

    Sorry if i wouldn't be of help but, i believe that it doesn't worth too much to retrieve those value while those PIC are really cheap, just throw it away and use another one. The next time just read the value in, then write it down on a paper or use liquidpaper underneath your PIC and write value there.

    BUT Melanie already post something on that
    http://www.picbasic.co.uk/forum/show...84&postcount=2
    Steve

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

  3. #3
    Join Date
    Apr 2005
    Posts
    96


    Did you find this post helpful? Yes | No

    Default

    I appreciate the suggestion, I can throw away the chip and resolder a new one on, but I want to figure out how to keep this from happening again. I have killed 2 chips already and I know every other one I program will be dead unless I change something.

    Do you know if the MELABS programmer will automatically skip the OSCAL and BandGap settings? I need to program 1000s of these once i get this figured out and can't afford the time of writing down the OSCAL values of every chip.

    I am not even sure the OSCAL value being deleted is the problem, as I understand it I should still be able to reprogram the chip if that were the case and the internal oscillator would just be off by a little. At this point the programmer won't let me reprogram or erase the chip.

  4. #4
    Join Date
    Jul 2003
    Posts
    2,358


    Did you find this post helpful? Yes | No

    Default

    OSCAL and bandgap are unimportant in making your PIC work.

    When you ERASe, all you ERASE is the program codespace and perhaps the EEPROM, the CONFIG settings are untouched.

    Just write a simple LED Blink Program for Internal Oscillator and Internal MCLR (ie MCLR as an I/O (Input) pin) and burn that into your PIC. You'll probably find it works.

  5. #5
    Join Date
    Apr 2005
    Posts
    96


    Did you find this post helpful? Yes | No

    Default

    That's what I thought Melanie but when I tried that the chip locked up and won't allow for an erase or a reprogram.

    Should it matter that I have a 5k pull-down resistor on the MCLR pin since I am using it as an input? I think I also have 5k pull-downs on the ICSPData and ICSPCLK pins also.

    I'm starting to think this is more of a schematic issue then a config issue.

    Thanks again for any thoughts, they are much appreciated

  6. #6
    Join Date
    Jul 2003
    Posts
    2,405


    Did you find this post helpful? Yes | No

    Default

    Programming in-circuit can be tricky is you have Vpp, data and clock pins tied to the application circuit.

    Programming voltage on /MCLR needs to rise fast enough to prevent the program counter from incrementing. If it does not rise fast enough, your code previously programmed into the device can start executing, and it screws up the whole process. In this case, you're trying to program a PIC that's already executing code, and is no longer in program mode.

    The internal RC osc makes the start-up process even faster, so it's even more critical for Vpp to rise fast.

    Try lifting the pull-down resistor you have on /MCLR, and make sure you have the programming clock & data pins disconnected from any external loads.

    External loads on data & clock pins will also screw up ICSP.

    That should allow you to re-program & erase in-circuit without any problems assuming the PIC isn't dead.
    Regards,

    -Bruce
    tech at rentron.com
    http://www.rentron.com

  7. #7
    Join Date
    Apr 2005
    Posts
    96


    Did you find this post helpful? Yes | No

    Default

    I'll give that a shot, but that basically means taking the pic out of the circuit using jumpers or I will loose 3 of the 6 GPIOs. I thought the pic should be able to handle this, I will try pulling the MCLR pull-down off first to see what that does and go from there. If the program programs the first time, should the clock and data pins really matter?

    Thanks

  8. #8
    Join Date
    Jul 2003
    Posts
    2,405


    Did you find this post helpful? Yes | No

    Default

    Yes the clock & data pins definitely matter if you program in-circuit. A load on the clock pin in particular will really mess with timing.

    Read Microchips' DS91017B ICSP guide for a detailed explanation.
    Regards,

    -Bruce
    tech at rentron.com
    http://www.rentron.com

  9. #9
    Join Date
    Sep 2003
    Location
    Vermont
    Posts
    373


    Did you find this post helpful? Yes | No

    Talking

    Quote Originally Posted by Bruce
    Yes the clock & data pins definitely matter if you program in-circuit. A load on the clock pin in particular will really mess with timing.

    Read Microchips' DS91017B ICSP guide for a detailed explanation.
    I had the same issue rear it's ugly head some months back. If your code is evolving, you really should keep MCLR as a reset. The last programming action will be to flip the config fuse for the MCLR pin to become an input. If you place a 1 K resistor between the clock pin and the circuit it is attached to, this will help. Same with Data pin. For ICSP, I raise the pullup resistor to MCLR to 22K. It helps when your power supply is 2 to 3 volts and the programming power is 5 volts. If that's not enough, a schottky diode from B+ to the VDD pin will allow ICSP in a circuit that can't take 5 volts. I fried come 3 volt comm chips this way before the stupid light went off!
    I perconally traded the 12F series for the 16F690 in the 4 mm package. 18 GPIOs and 4 K of flash memory!Boy is this living!

  10. #10
    Join Date
    Apr 2005
    Posts
    96


    Did you find this post helpful? Yes | No

    Default Very Odd

    Well I figured out the issue, not the solution but the issue.

    I completely isolated the chip and it would still not program so, I went ahead and replaced the chip and it programmed fine. I got pin GP.2 blinking an LED so that was successful.

    Still leaving the MCLR, ICSPDat and ICSClk isolated I decided to try and toggle pin GP.1

    As soon as I do this the my MELabs throws a Config error while programming and the chip becomes useless, no programability or eraseability just like my first post.

    Any clue why the board is doing this? Here is a snipit of my code

    [code\]
    DEFINE OSCCAL_1K 1
    ' Config Fuses
    @ __config _INTRC_OSC_NOCLKOUT & _CPD_ON & _CP_ON & _BODEN_ON & _MCLRE_OFF & _PWRTE_ON & _WDT_ON

    ' Variable Definitions
    LED VAR GPIO.1

    blink var bit


    CMCON=7
    TRISIO=%11111001 ' Input 0,3,4,5 Output 1,2
    ANSEL=0

    Main:
    blink=blink+1
    led=blink
    pause 100
    goto main

    [\code]


    If I change this code to apply to pin GP.2 it works fine and will reprogram all day long

    Thanks for any help
    Last edited by modifyit; - 18th May 2006 at 05:29.

  11. #11
    Join Date
    Apr 2005
    Posts
    96


    Did you find this post helpful? Yes | No

    Unhappy Just killed another one

    Just killed another one, here is the error thrown by MELABS

    "Configuration Error at 0000, 0000 should be 004C. Continue verifying?"

    Thanks again for any thoughts...btw when programing the chip the program works, just throws that error when "verifying" and then won't program or erase

  12. #12
    Join Date
    Apr 2005
    Posts
    96


    Did you find this post helpful? Yes | No

    Default

    I just got a note back from MELabs stating that you can not reliably program the 12F675 when using both MCLR as an input and the internal oscillator.

    I guess I will try making the MCLR as a reset pin later and see if another chip bites the dust.

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


    Did you find this post helpful? Yes | No

    Default

    probably but as i've tons of design who use internal OSC and MCLR as i/o, i'll probably mostely bet on the CodeProtect stuff. Sure you can reprogram but can't read back. This is probably why you got this error.

    ALSO, you may look at the programming sequence and idle state. Some design may ruine your life when using ICSP. Same thing for some device programmer... like PICSTART wich is still great but sometimes a pain in ICSP.

    How about doing another test... remove any load on ICSPdata, ICSPClk, and place a 10K pull-up + diode on MCLR pin like...http://www.melabs.com/support/icsp.htm


    Then now, remove your code protection (CP and CPD), program ir, erease it. Once done, place your load on ICSPdata, ICSPclk and redo the same... about now??? If problem persist, how about if you shut down the unit, connect it to your programmer, the power-up the unit?

    Now do the same thing with the MCLR. About now?

    Set your code protect.... aboout now?
    Last edited by mister_e; - 18th May 2006 at 17:47.
    Steve

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

  14. #14
    Join Date
    Sep 2003
    Location
    Vermont
    Posts
    373


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by modifyit
    I just got a note back from MELabs stating that you can not reliably program the 12F675 when using both MCLR as an input and the internal oscillator.

    I guess I will try making the MCLR as a reset pin later and see if another chip bites the dust.

    I repeat...

    <<If your code is evolving, you really should keep MCLR as a reset. The last programming action will be to flip the config fuse for the MCLR pin to become an input.>>

  15. #15
    Join Date
    Sep 2003
    Location
    Vermont
    Posts
    373


    Did you find this post helpful? Yes | No

    Default

    Let's try that again...

    If your code is evolving, you really should keep MCLR as a reset. The last programming action will be to flip the config fuse for the MCLR pin to become an input.

  16. #16
    Join Date
    Apr 2005
    Posts
    96


    Did you find this post helpful? Yes | No

    Default

    Ahh that could make some sense then...If the last thing the programer does is flip the MCLR to being an input, that is why it could be crashing the MELABS programmer and corrupting the chip, but the chip's program seems to run fine.

    I will try using the MCLR as a reset and see what happens.

    Thanks again

  17. #17
    Join Date
    Apr 2005
    Posts
    96


    Did you find this post helpful? Yes | No

    Default

    Making the MCLR a reset did the trick. Thanks to all for your thoughts

Similar Threads

  1. Winbond ISD1700 Voice Recorder
    By RFEFX in forum mel PIC BASIC Pro
    Replies: 58
    Last Post: - 22nd April 2014, 11:00
  2. 12F683 vs 12F675.
    By sccoupe in forum mel PIC BASIC Pro
    Replies: 1
    Last Post: - 11th July 2009, 05:58
  3. LANC code 12F675
    By MikeDD in forum General
    Replies: 4
    Last Post: - 9th May 2008, 06:44
  4. serout out of order on 12F675
    By Ricardo in forum Serial
    Replies: 7
    Last Post: - 29th April 2008, 01:16
  5. 12F675 code sample
    By marad73 in forum mel PIC BASIC Pro
    Replies: 9
    Last Post: - 23rd May 2006, 14:53

Members who have read this thread : 1

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