Hot!Error while programming PIC12F675

Author
sphari
New Member
  • Total Posts : 18
  • Reward points : 0
  • Joined: 2014/05/29 04:43:17
  • Location: 0
  • Status: offline
2017/09/01 12:16:07 (permalink)
0

Error while programming PIC12F675

hi..
 
I am facing error while programming my PIC12F675 chip. the error is "Address: 0 Expected Value: 2bfd Received Value: 3fff" 
 
Settings in MPLAB IPE:
Power: from PICKET 3
voltage: 3.25
 
Initially i was powering my chip externally with 5 volt but it was giving error while connecting PICKIT3 to target board as "
Target Device ID (0x0) does not match expected Device ID (0xfc0).
Target has invalid calibration data (0x3f)."
After powering the chip from target above error vanished and new error started that is 
 "Address: 0 Expected Value: 2bfd Received Value: 3fff" 
 
Please give me your valuable suggestions to resolve it
#1

6 Replies Related Threads

    NKurzman
    A Guy on the Net
    • Total Posts : 14834
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: Error while programming PIC12F675 2017/09/01 12:25:57 (permalink)
    +1 (1)
    So you are getting a correct ID Now?
     MPLAB IPE Version  what?
     
    0x3FF is the erased value.  it would indicate it is not programming.
    How much current does your Board Need? the Pickt3 does not provide alot.
    Does your PCB have the Proper capacitors?
     
    #2
    RISC
    Super Member
    • Total Posts : 4477
    • Reward points : 0
    • Status: offline
    Re: Error while programming PIC12F675 2017/09/01 14:40:32 (permalink)
    +1 (1)
    Hi,
    From the PIC12F675 specification, it seems that the BULK erase of this device can only happen between 4.5V to 5.5V.
    Even if you are an error message (due to some other reason), I guess you must power your PIC between  4.5V to 5.5V .
    Please describe your board (or breadboard) ICSP connections
    Regards
     
    #3
    NKurzman
    A Guy on the Net
    • Total Posts : 14834
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: Error while programming PIC12F675 2017/09/01 16:25:23 (permalink)
    +1 (1)
    Oh one of those old PICs.  Good catch.
    #4
    ALPL
    Super Member
    • Total Posts : 263
    • Reward points : 0
    • Joined: 2006/12/30 02:52:11
    • Location: Austria
    • Status: offline
    Re: Error while programming PIC12F675 2017/09/10 00:44:09 (permalink)
    +4 (4)
    Hello sphari,
    after programming PICs for years, we encountered the same problem some months ago (we never thought that this would happen to us wink: wink). We used a PIC18F1320 as a frequency counter for flow rate sensors. Settings (for the prototype on a breadboard) were: MCLR:OFF , INTOSC: 4 MHz. We used TMR1 as a counter.
     
    First time programming: everything OK. Then we made some software changes. Second time programming: we got the nice message "Target Device ID (0x0 or any other value) does not match expected Device ID ...". Nothing helped any more - the device could not be programmed any more. Maybe the PIC was defective? We tried another 4! Same result. Then we tried 2 PIC16F690 - same result! After a quite long research in PIC forums we found the information (from member PIC2Dev) that:
     
    The problem occurs when the device is programmed so that:
    1) It uses the internal oscillator
    -and-
    2) The MCLR pin is turned off to use as a digital input instead
    -and-
    3) The program code enabled the Timer1 Oscillator in the T1CON register.  (The sooner this is enabled after the reset vector the more likely the problem is to occur.
     
    Revival of the dead PICs: Some suggestions were to play with Vdd or simply turn MPLAB/PICkit3/PIC on and off. I have to say that with 2 PIC18F1320 this worked - after playing around suddenly they were "alive" again and could be reprogrammed - the other PICs remained dead.
     
    Other people suggested to try to reprogram the bad PIC using "Use VPP First Program Entry" (this option can be found in MPLAB IPE or the older PICKIT2 software; programming with a PICkit3 behaving as a PICkit2). "Use VPP First Program Entry" with IPE worked for 1 other PIC18F1320 and both PIC16F690 - but after doing this procedure several times! 2 PIC18F1320 are still "dead". We did not find out why this sometimes worked and why sometimes not.
     
    We also found explanations that when "Use VPP First Program Entry" is not set the PIC when powered ON immediately starts to run (increases the program counter) before PICkit3 or another programmer can start the programming procedure. So the programming counter is not at 0x00 but somewhere else when the programming starts.
     
    MCLR: enable (with 10K tied to Vdd) or not did not make a difference in our case. But what we found out was that enabling Timer1 at the beginning of the software while using the internal oscillator was the main reason for the problems. Some people suggested that putting a delay (some said 40ms is enough, some said that 2sec or more are needed) before enabling TMR1 solves the problem - unfortunately not in our case.
     
    Also there is following note in the PIC18F1320 datasheet (maybe this also applies to other PICs):
     
    "Note: The Timer1 oscillator shares the T1OSI and T1OSO pins with the PGD and PGC
    pins used for programming and debugging.
    When using the Timer1 oscillator, In-Circuit Serial Programming (ICSP) may not
    function correctly (high voltage or low voltage), or the In-Circuit Debugger (ICD) may
    not communicate with the controller. As a result of using either ICSP or ICD, the
    Timer1 crystal may be damaged.
    If ICSP or ICD operations are required, the crystal should be disconnected from the
    circuit (disconnect either lead) or installed after programming. The oscillator loading
    capacitors may remain in-circuit during ICSP or ICD operation."
     
    So my suggestion is to always use the "Use VPP First Program Entry"-option and to avoid INTOSC and TMR1 in the software. This is actually very annoying - you will find countless posts about this issue. Microchip should find a solution to fix this problem so it is possible to use INTOSC and TMR1 safely in an application without having mysterious effects and many lost hours for trying/searching.
     
    I hope that this post will trigger other posts from more experienced users to put more light on this issue.
    #5
    Ian.M
    Super Member
    • Total Posts : 13046
    • Reward points : 0
    • Joined: 2009/07/23 07:02:40
    • Location: UK
    • Status: online
    Re: Error while programming PIC12F675 2017/09/10 23:42:15 (permalink)
    +1 (1)
    The Timer 1 oscillator issue is unique to 18 pin PICs that share the T1OSO and T1OSI  pins with PGD and PCC respectively.  T1OSO has more drive than most programmers can overcome, so If the Timer 1 oscillator is enables, when T1OSI is pulled low by the programmer it forces T1OSO high.  If external /MCLR is disabled and the code enables Timer 1 Oscillator immediatly after powerup, it will breach the requirement that both PGD and PGC be low at the rising edge of /MCLR as it goes up to Vpp for program mode entry.
     
    PICkit2Dev explained the issue and the remedy here: http://www.microchip.com/forums/FindPost/308594
    However, it cant affect any PICs except the 18 pin ones because on all other devices Timer 1 doesn't share pins with the ICSP interface.   There is however a similar issue when either PGC and/or PGD is set as an output and /MCLR is disabled that can affect any 8 bit PIC that uses high voltage programming, which is what is affecting the O.P's PIC12F675.  Recovery is similar to PICkit2Dev's procedure for the 18 pin PIC Timer 1 oscillator issue.  Using a programming tool that supports Vpp first mode, keep on trying to erase while dropping the voltage until it takes. 
     
    However, as the calibration has already been lost, the internal oscillator will be running at the wrong frequency,  XC8 or assembler startup code that trys to read the factory OSCCAL value by calling the RETLW at the top of the program memory will crash, wrapping around back to address 0x000, and also the bandgap reference will probably be miscalibrated resulting in an incorrect BOR threshold.
     
    See http://www.microchip.com/forums/m990997.aspx for  OSCCAL recalibration using the PICkit 2 software and more about the causes of the issue
     
    See http://www.microchip.com/forums/m990997.aspx for accessing the OSCCAL RETLW using IPE - its about the OSCCAL MOVLW on a PIC10F200 but the principle is the same apart from the difference in opcode and calibration value address.
     
    See http://www.microchip.com/forums/FindPost/635944 for bandgap calibration recovery using the PICkit 2 standalone software.
     
     

    --
    NEW USERS: Posting images, links and code - workaround for restrictions.
    I also support http://picforum.ric323.com because this forum is sometimes too broken to use!
    #6
    ALPL
    Super Member
    • Total Posts : 263
    • Reward points : 0
    • Joined: 2006/12/30 02:52:11
    • Location: Austria
    • Status: offline
    Re: Error while programming PIC12F675 2017/09/13 10:00:08 (permalink)
    0
    @Ian.M: thank you for this valuable information! Finally I understand the problem now and also how to avoid/fix it.
    #7
    Jump to:
    © 2017 APG vNext Commercial Version 4.5