Jetroid
New Member
- Total Posts : 5
- Reward points : 0
- Joined: 2016/02/13 13:06:46
- Location: 0
- Status: offline
Programming PIC causes Device ID to become unrecognisable
Hi All, I'm working with the PIC16F88, and have used it in several other projects in the past. I can therefore confirm that there is no problem with my hardware configuration as I don't experience any problems when I try to program my other projects. My most recent code commit causes the PIC to gain an unrecognisable Device ID when programmed. Steps: Press Make and Program Device Main Project Device ID recognised, Device Erased, Programming, program/verify complete, etc Press Make and Program Device Main Project a second time (Even without removing the PIC from the burner) "Target Device ID (0x0) is an Invalid Device ID. Please check your connections to the Target Device." If I press "OK" to continue, I see (regular output followed by): Address: 0 Expected Value: 2a1b Received Value: 0 Failed to program device If I try to reprogram one of these 'killed' PIC with another 'known good' project, then I experience the same problems. Strangely, my code seems to burn onto the device correctly, as these 'killed' PICs continue to function in my application. I'm programming the PICs with assembly and a genuine PICkit 3, am using ~800 of my 4K of program memory, am using all of my 256 EEPROM bytes. HVP is being used and the PIC in the programming jig is powered from a (tested good) external 5V source. Configuration words are 2D58 / 3FFC. I'm kind of flummoxed by this, and to date I've rendered 6 PIC16F88s non-functional by trying to write to them after commenting some sections of code out to try to narrow down the problem. I only have a few of these devices left now and I don't want to ruin more (and run out). I also don't want to revert the commit as I need the functionality it implements (and I've seen it working, because, as stated previously, the chip still functions, I just can't read it/burn it anymore). Does anyone have any idea what I'm doing wrong or what is going wrong here? Jet Holt
post edited by Jetroid - 2019/12/05 09:27:08
|
NKurzman
A Guy on the Net
- Total Posts : 19185
- Reward points : 0
- Joined: 2008/01/16 19:33:48
- Location: 0
- Status: offline
Re: Programming PIC causes Device ID to become unrecognisable
2019/12/05 09:38:39
(permalink)
Are you Disabling MCLR? in the Config Bits? LVP or HVP in the config bits? And the Programmer?
|
jack@kksound
code tags!
- Total Posts : 3227
- Reward points : 0
- Joined: 2014/05/14 10:03:19
- Location: 0
- Status: offline
Re: Programming PIC causes Device ID to become unrecognisable
2019/12/05 09:41:23
(permalink)
Some of the older pics had an issue with programming if the MCLR was disabled (as you have) and PORTB was set to output mode too quickly out of reset, a delay was needed before changing the direction of the port pins to allow the entry into programming mode correctly (I think I have this right, been a while).
|
Jetroid
New Member
- Total Posts : 5
- Reward points : 0
- Joined: 2016/02/13 13:06:46
- Location: 0
- Status: offline
Re: Programming PIC causes Device ID to become unrecognisable
2019/12/05 09:47:02
(permalink)
@NKurzman As mentioned, my Configuration words are 2D58 / 3FFC. FOSC : INTOSCIO WDTE : OFF PWRTE : OFF MCLRE : OFF BOREN : ON LVP : OFF CPD : OFF WRT : 256 CCPMX : RB3 CP : OFF FCMEN : OFF IESO : OFF
@jack@kksound: That's interesting, I hadn't heard about that. Indeed, PORTB is mostly set to digital outputs for me. Where can I read more about this phenomenon, as a cursory google search isn't leading me to anything about that? What kind of delay is needed?
|
Jetroid
New Member
- Total Posts : 5
- Reward points : 0
- Joined: 2016/02/13 13:06:46
- Location: 0
- Status: offline
Re: Programming PIC causes Device ID to become unrecognisable
2019/12/05 10:04:50
(permalink)
@jack@kksound Yep, that seems to be the problem. I added a 100ms delay before my code and now I don't see a problem. Is there any way to recover my chips that have the old code? Regards, Jet Holt.
|
jack@kksound
code tags!
- Total Posts : 3227
- Reward points : 0
- Joined: 2014/05/14 10:03:19
- Location: 0
- Status: offline
Re: Programming PIC causes Device ID to become unrecognisable
2019/12/05 10:06:51
(permalink)
Search this forum, should be somewhere. A long enough delay to allow the pickit3 to perform the programming setup steps. I am not sure what that would be however maybe someone else here with more specific knowledge will offer it up.
|
jack@kksound
code tags!
- Total Posts : 3227
- Reward points : 0
- Joined: 2014/05/14 10:03:19
- Location: 0
- Status: offline
Re: Programming PIC causes Device ID to become unrecognisable
2019/12/05 10:08:05
(permalink)
I understand there is a setting in the pickit3 that may help, something about "Vpp first" program mode or like that. EDIT: I may have that setting name wrong, I can't look at it right now.
post edited by jack@kksound - 2019/12/05 10:11:15
|
ric
Super Member
- Total Posts : 30201
- Reward points : 0
- Joined: 2003/11/07 12:41:26
- Location: Australia, Melbourne
- Status: online
Re: Programming PIC causes Device ID to become unrecognisable
2019/12/05 12:22:33
(permalink)
Yes, it is "Vpp before Vdd" mode that is required. The OP has not mentioned if they are using MPLABX or MPLAB8 to do the programming.
To get a useful answer, always state which PIC you are using!
|
Jetroid
New Member
- Total Posts : 5
- Reward points : 0
- Joined: 2016/02/13 13:06:46
- Location: 0
- Status: offline
Re: Programming PIC causes Device ID to become unrecognisable
2019/12/05 12:38:41
(permalink)
@ric, I'm using MPLABX v5.05 with a PICkit 3 on Linux. I don't see a "Vpp before Vdd" option in my project properties. Does it require using the PICkit 3 to power the target?
post edited by Jetroid - 2019/12/05 12:50:07
|
ric
Super Member
- Total Posts : 30201
- Reward points : 0
- Joined: 2003/11/07 12:41:26
- Location: Australia, Melbourne
- Status: online
Re: Programming PIC causes Device ID to become unrecognisable
2019/12/05 14:19:55
(permalink)
Jetroid ... Does it require using the PICkit 3 to power the target?
Yes. The PK3 must be controlling both to be able to raise Vpp before Vdd. If you go into your project properties, select the PK3, and select "Program options" from the dropdown, the last option should be "Programming method", and the two options are: - "Apply Vpp before Vdd (Recommended)"
- "Apply Vdd before Vpp"
To get a useful answer, always state which PIC you are using!
|
ric
Super Member
- Total Posts : 30201
- Reward points : 0
- Joined: 2003/11/07 12:41:26
- Location: Australia, Melbourne
- Status: online
Re: Programming PIC causes Device ID to become unrecognisable
2019/12/05 14:20:55
(permalink)
You may find that just enabling the PK3 to power the PIC is all you need to be able to reprogram the chips.
To get a useful answer, always state which PIC you are using!
|
EverGreen_28
Starting Member
- Total Posts : 55
- Reward points : 0
- Joined: 2018/08/14 11:09:01
- Location: Argentina
- Status: offline
Re: Programming PIC causes Device ID to become unrecognisable
2019/12/05 14:48:27
(permalink)
In version 5.05 and 5.10 has no option to "VPP before VDD" In version 5.20 (actually i used) the option exist. I recommend to update to at least 5.20
post edited by EverGreen_28 - 2019/12/05 14:49:54
|
LucaAg
New Member
- Total Posts : 3
- Reward points : 0
- Joined: 2019/12/05 05:26:57
- Location: 0
- Status: offline
Re: Programming PIC causes Device ID to become unrecognisable
2019/12/05 14:58:49
(permalink)
Hi Jet, I experimented the same problem, more than once, when sometimes I made wrong GND reference connection. In example I was debugging an application, supplying the target board with an isolated transformer, and than I conncted the scope probe. Probably due to a pretty high current flowing on the EARTH connection, the PIC broke and I was no more able to program it. So, my advise, if you're debugging the board, avoid to connect it to any other electrical device, if not fully isolated. Rgds, Luca
|
hudejun
Electrical engineer
- Total Posts : 15
- Reward points : 0
- Joined: 2019/12/05 08:48:06
- Location: 0
- Status: offline
Re: Programming PIC causes Device ID to become unrecognisable
2019/12/05 16:49:52
(permalink)
Are you using RB6 and RB7 as output pin? Then, it should be set to input for a few milliseconds at the start of the power. If firmware control output(RB6&7) without delay at the first moment, it will be bricked continuously.
|
Jetroid
New Member
- Total Posts : 5
- Reward points : 0
- Joined: 2016/02/13 13:06:46
- Location: 0
- Status: offline
Re: Programming PIC causes Device ID to become unrecognisable
2019/12/05 20:13:56
(permalink)
I just upgraded to 5.30, but I still don't see 'VPP before VDD' in my project properties.
Attached Image(s)
|
ric
Super Member
- Total Posts : 30201
- Reward points : 0
- Joined: 2003/11/07 12:41:26
- Location: Australia, Melbourne
- Status: online
Re: Programming PIC causes Device ID to become unrecognisable
2019/12/05 20:33:26
(permalink)
Same here. I do see it if I select other model PICs, but it disappears if I select PIC16F88. If you could somehow force RB6 and RB7 low when MCLR/Vpp was low, but release them as soon as it was raised, you MIGHT be able to erase the PIC, which would get you out of trouble. I'm not sure how you'd do that without a lot of external circuitry though.
To get a useful answer, always state which PIC you are using!
|
NorthGuy
Super Member
- Total Posts : 6580
- Reward points : 0
- Joined: 2014/02/23 14:23:23
- Location: Northern Canada
- Status: online
Re: Programming PIC causes Device ID to become unrecognisable
2019/12/05 21:00:11
(permalink)
Remove power from your PIC. Build a circuit which powers your PIC at 5V when MCLR goes to 13V - the simplest way is an 8 V zener between MCLR and VDD, or a chain of diodes. Configure PICkit3 not to provide power, disconnect VDD pin of the PICkit3 connecter from your PIC and connect it to 5V. Then erase.
|
Ian.M
Super Member
- Total Posts : 13274
- Reward points : 0
- Joined: 2009/07/23 07:02:40
- Location: UK
- Status: offline
Re: Programming PIC causes Device ID to become unrecognisable
2019/12/06 01:37:36
(permalink)
The PICkit 3 Vpp/MCLR output cant supply much current and overloading it can kill your PICkit 3. A better approach to hacking Vpp first mode in hardware is to run the target Vdd supply through a N-MOSFET from external 5v, with its gate driven by Vpp. You may need a 1K resistor in series with the gate to reduce the loading on Vpp during transitions. You may also need a pull-down resistor on target Vdd. You'll still need the programmer Vdd connected to 5V so it 'knows' it can't control Vdd, as NorthGuy mentioned above. However the old PICkit 3 standalone software v3.10 supports VPP first mode, and that would be my first choice for salvaging 'locked out' parts
post edited by Ian.M - 2019/12/06 08:03:53
|
oliverb
Super Member
- Total Posts : 435
- Reward points : 0
- Joined: 2009/02/16 13:12:38
- Location: 0
- Status: offline
Re: Programming PIC causes Device ID to become unrecognisable
2019/12/06 01:46:04
(permalink)
You have brown-out reset enabled. Is it possible to try erasing with a VDD below the brown-out threshold, so the program doesn't start? It looks as if the threshold is 4V. Even if it corrupts you should'd then be able to re-program at 5V.
|
atferrari
Super Member
- Total Posts : 1464
- Reward points : 0
- Joined: 2004/07/08 13:09:24
- Location: Buenos Aires - Argentina
- Status: offline
Re: Programming PIC causes Device ID to become unrecognisable
2019/12/06 06:23:09
(permalink)
What about with PICkit4? Should I care of something? Just one week using it with good results so far. No previous experience with any PICkitx-
|