Author Topic: device failure on PICKIT2 (Read 22790 times)

Simon · « **on:** October 19, 2012, 08:18:09 pm »

I'm trying to program a 16F883 with my pickit2 but it won't recognize the "device", could it be the 3" wires that link from the pickit2 to the ziff socket ?

Baliszoft · « **Reply #1 on:** October 19, 2012, 08:21:04 pm »

I usually got around 10" of cable for icsp and works without problems.

Simon · « **Reply #2 on:** October 19, 2012, 08:25:34 pm »

hm very odd, i'm getting sporadic behaviour

Simon · « **Reply #3 on:** October 19, 2012, 08:31:19 pm »

it will write to the pic but then when I try to read says it failed at address 0x000000 or that no device was detected

DrGeoff · « **Reply #4 on:** October 19, 2012, 08:34:53 pm »

What's the power arrangement during this?

Simon · « **Reply #5 on:** October 19, 2012, 08:44:23 pm »

I have the pickit plugged into a small adapter board I made, male 90deg header in, connected straight to a female header, a female header down each side of the zif socket and i use 3" jumper wires to connect the pickit header to the pic headers. The power is coming from the pickit, no other power involved

Baliszoft · « **Reply #6 on:** October 19, 2012, 08:53:57 pm »

Check the voltage settings on the pickit (and verify if that matches the actual output).

Simon · « **Reply #7 on:** October 19, 2012, 08:57:51 pm »

4.7-4.85, ticking the box in the interface to make it power the target pic seems to have resolved it......... i have the latest software and pickit firmware

djsb · « **Reply #8 on:** October 19, 2012, 09:23:30 pm »

Have you got pin 1 (MCLR) tied to 5V with a 10K resistor? This is needed. This topic may also be useful.

http://www.microchip.com/forums/m330142.aspx

David.

Simon · « **Reply #9 on:** October 20, 2012, 06:28:31 am »

Quote from: djsb on October 19, 2012, 09:23:30 pm

Have you got pin 1 (MCLR) tied to 5V with a 10K resistor? This is needed. This topic may also be useful.

http://www.microchip.com/forums/m330142.aspx

David.

There is a Vpp/MCLR pin on the pickit2 that I connect to that pin

AndyC_772 · « **Reply #10 on:** October 20, 2012, 07:25:38 am »

It still needs a separate 10k pull-up between MCLR# and VCC, though - but it sounds as though you've resolved your problem by getting the PICKIT to actually power the board. Without it, the PIC might still have been powered through its inputs, so although I'm surprised it ever worked at all, it's not impossible.

djsb · « **Reply #11 on:** October 20, 2012, 07:26:44 am »

Try connecting the 10k resistor AS WELL.

David.

Simon · « **Reply #12 on:** October 20, 2012, 07:31:18 am »

I'm confused because there is a dedicated VPP/MCLR pin on the pickit so that would lead to assume that you leave it to the pickit. I'll try it when i next flash a chip.

AndyC_772 · « **Reply #13 on:** October 20, 2012, 07:45:56 am »

Assumption is the mother of all f***-ups!

Simon · « **Reply #14 on:** October 20, 2012, 07:50:54 am »

is the 10K resistor requirement stated in the pickit manual ?

djsb · « **Reply #15 on:** October 20, 2012, 08:34:41 am »

Don't know, as I've not read the PK2 manual. We use PICKit 3 and ICD3 at work (and the occasional student uses PICKit 2) and they ALL work with the board I developed that has a 10K resistor to +5V (and a push button reset to ground). Also try to leave the 2 ICSP pins clear of any load (LED's etc) as this can effect the programming.

I used this as a guide.

http://ww1.microchip.com/downloads/en/DeviceDoc/DS-51765C.pdf

David.

Simon · « **Reply #16 on:** October 20, 2012, 08:58:27 am »

well yes I think there is scope for using the MCLR pin in the circuit as a MCLR that is shared with the VPP of the pickit so the pickit will be made to deal with it as it's a common scenario and they chose to make those pins dual function. but i think purely for programming you should need any extra components.

Yes I try to leave the ICSP pins free in a design so that I can change the firmware without taking the chip out.

AndyC_772 · « **Reply #17 on:** October 20, 2012, 09:10:22 am »

Quote from: the data sheet

An internal MCLR option is enabled by clearing the
MCLRE bit in the Configuration Word Register 1. When
MCLRE = 0, the Reset signal to the chip is generated
internally. When the MCLRE = 1, the RA3/MCLR pin
becomes an external Reset input. In this mode, the
RA3/MCLR pin has a weak pull-up to VDD.

MCLR/VPP is used in two ways during programming: as a device reset (to put it into programming mode in the first place), and as VPP to provide the high voltage necessary to program the Flash memory. It may be that, especially if you don't already have MCLRE programmed as 1, the programming sequence doesn't work because MCLR doesn't go high when it should.

Seriously, though... it's only a 10K resistor, that's all. Just try it if you still have a problem!

Have you not already fixed it by powering the device correctly? Or are you still having problems even after getting the PICKIT to provide power to the board? It sounds from what you said as though you only had problems when the PIC wasn't being powered from anywhere at all - and that's hardly surprising

Simon · « **Reply #18 on:** October 20, 2012, 09:22:52 am »

Yes the problem was resolved by ticking the box on the pickit interface to power the pic, I thought this was a manhual only control put there so that you can use the pickit as a power supply too (up to 50 or 100mA) so it's nothing to do with programing but yes it fixed it, if the software knows that the target needs power it should provide it.

I'm not using the MCLR as a MCLR pin but as an I/O (well nothing at all I think).

My point is that I'm doing as instructed but things are not working. So maybe there is a problem with the software or the manual. As I'm giving the pickit exclusive access and control of the target pic I'd expect it to "deal with it" I've not done anything the pickit can't do itself if needed

Simon · « **Reply #19 on:** October 20, 2012, 05:06:30 pm »

it's doing it again now even with the pic powered from the pickit. Now i pissed off, what is it with this shit programmer !

Simon · « **Reply #20 on:** October 20, 2012, 05:28:50 pm »

I can read the device but not program it, this all used to work before why is it suddenly doing this ? faulty programmer ?

Baliszoft · « **Reply #21 on:** October 20, 2012, 05:33:16 pm »

Pickit2 is a good programmer imho. Maybe you are doing something wrong?

My pickit2 already had lots of abuse (overload on target power, overload on gnd), the only issue i had with it, that somehow i managed to erase its calibration memory (dont ask how), and it wasn't sending out the requested target voltage. After a re-calibration it was good as new.

djsb · « **Reply #22 on:** October 20, 2012, 05:33:23 pm »

Please be more specific. What is "it"? Did you put the 10k resistor on the MCLR pin? Which pins on the Pickit 3 are connected to which pins on the device. Do you get any message at all in MPLAB? What configuration fuses are you using (are they in your source code listing or set up in MPLAB?Have you tried powering the target from a separate supply and not the Pickit?Is your device plugged in securely? I could go on with the questions but I'll just give you a chance to answer.

David.

mariush · « **Reply #23 on:** October 20, 2012, 05:35:12 pm »

Use a 4.7k-10k resistor between the MCLR and 5v power of the chip, see chapter 2 in the manual attached.

Jon Chandler · « **Reply #24 on:** October 20, 2012, 05:36:02 pm »

Here is a compilation of common PIC problems: Commandments For Using PICs

A couple points come to mind:

1. Do you have a 0.1 uF bypass cap across the power pins? Problems with this show up in all kinds of ways.

2. I would recommend against disabling /MCLR, even if it means using the ICSP pins for I/O.

3. The PICkit 2 will properly pull up /MCLR when the PICkit is connected, but you'll need the 10k resistor to allow the board to run reliably with the PICkit disconnected.

4. If you want the PICkit to power the micro, tick the box. (That really seems pretty straightforward.)

5. If the PICkit errors because of a power short, you must disconnect it from USB, shut down the GUI and start over. In the event of communication errors or other problems programming, I would also do this. The PICkit will protect itself from supplying excess power, but needs to be disconnected from USB to reset.

6. If the GUI freezes and can't be closed, it's usually because of a power short. See #5.

Hope this helps. The PICkit 2 has been solid for me.

Simon · « **Reply #25 on:** October 20, 2012, 05:38:02 pm »

Quote from: djsb on October 20, 2012, 05:33:23 pm

Please be more specific. What is "it"? Did you put the 10k resistor on the MCLR pin? Which pins on the Pickit 3 are connected to which pins on the device. Do you get any message at all in MPLAB? What configuration fuses are you using (are they in your source code listing or set up in MPLAB?Have you tried powering the target from a separate supply and not the Pickit?

David.

Well tried a 1K to no avail, I'll dig out a 10K and retry. but I repeat I have never had these issues until now, other day worked fine.

Simon · « **Reply #26 on:** October 20, 2012, 05:39:25 pm »

I keep getting "no device detected"

I thought MCLR is a function of the pic in operation not programming, it just happens to be multiplexed with the Vpp

Jon Chandler · « **Reply #27 on:** October 20, 2012, 05:41:24 pm »

By the way, is your PICkit 2 "the real deal" from Microchip or a clone?

Some of the clones are very good, some skimp on the details. One area people get into trouble is programming 3 volts parts. Some of the clones left out the circuitry to control Vdd. Changing it in the GUI doesn't actually change the voltage supplied.

djsb · « **Reply #28 on:** October 20, 2012, 05:46:53 pm »

Which pins on your Pickit 2 are connected to which pins on your device?

Simon · « **Reply #29 on:** October 20, 2012, 05:47:35 pm »

it's a genuine one, one of those advertised at £17.50 and costing £35 by the time it got vat on, packed, shipped, shipping extra charge bla bla. I've hardly used it really.

Still no luck with a 10K resistor and programming in situ. I can read it but am getting: "programming failed at program memory address 0x000000"

This is on a 16F883, I'm totally pissed off, I'm supposed to be writing C code not trying to make a stupidly expensive programmer work.

I'll try re installing the firmware on the pickit although it is up to date !

Simon · « **Reply #30 on:** October 20, 2012, 05:49:30 pm »

Quote from: djsb on October 20, 2012, 05:46:53 pm

Which pins on your Pickit 2 are connected to which pins on your device?

16F883

pickit1 to pin 1
pickit2 to pin 20
pickit3 to pin 8
pickit4 to pin 28
pickit5 to pin 27

djsb · « **Reply #31 on:** October 20, 2012, 05:50:52 pm »

Put on an anti-static strap and fit a new chip.

David.

Simon · « **Reply #32 on:** October 20, 2012, 05:55:10 pm »

I just tried to reflash the pickit firmware and it failed, I now have no more pickit2 until i reload it. But this seems to point at USB communication now. could it be because it's plugged into a USB hub ?

I don't have an antistatic strap and to be honest I've treated pics far worse and they have been fine.

djsb · « **Reply #33 on:** October 20, 2012, 06:00:24 pm »

Yes, just try it without the hub. Your connections check out fine (sorry had to ask for confirmation). Sometimes the usb driver needs to re enumerate so removing/replugging it in seems to help.

David.

Jon Chandler · « **Reply #34 on:** October 20, 2012, 06:00:44 pm »

I have never gotten my PICkit to work reliably on a more-than-four port hub.

Also, using a non- powered hub has lead to problems too.

If the PIC has multiple power and ground pins, all must be connected.

Simon · « **Reply #35 on:** October 20, 2012, 06:02:46 pm »

Quote from: Jon Chandler on October 20, 2012, 06:00:44 pm

If the PIC has multiple power and ground pins, all must be connected.

oh ?

I'm getting no luck plugged into the pc's from USB port, and i mean after all every port on a PC is coming off a 2 port hub isn't it ?

djsb · « **Reply #36 on:** October 20, 2012, 06:02:54 pm »

Yes, I noticed that there are 2 VSS pins on the 883 (pins 8 and 19). Are they both connected to ground?

David.

Simon · « **Reply #37 on:** October 20, 2012, 06:05:13 pm »

just tried it with both connected, no joy, I'm also getting ever more pissed off with the pickit program enabling code protection just to complicate matters. It never used to do that either, what the hell is going on

Simon · « **Reply #38 on:** October 20, 2012, 06:07:03 pm »

um, remind me: an antistatic strap amounts to a piece of bare wire wrapped around my wrist and connected to the earth pin in a plug ? I can sort one of those. Do i need one for each hand or will one do ?

djsb · « **Reply #39 on:** October 20, 2012, 06:07:51 pm »

Device on it's last legs. Try a new one. Have a break and start again. If all else fails send it to me in a jiffy bag and I'll program it for you.

David.

djsb · « **Reply #40 on:** October 20, 2012, 06:09:24 pm »

Just one strap (with built in isolation resistor) is all that's needed.

David.

Simon · « **Reply #41 on:** October 20, 2012, 06:09:53 pm »

erm it's my first attempt at programming it and it is brand new, arrived yesterday. Yesterday all worked fine. now a total mystery. if you PM me your address I'll pop one of the offenders in the post and you can give it a go.

Simon · « **Reply #42 on:** October 20, 2012, 06:43:05 pm »

Well just tried getting a new chip out with a strap on (bar wire around wrist of hand dealing with chip connected to the earth pin of a mains plug via a 10K resistor). same lack of a result. I started to get this with my well used 16F88 chips as well and assumed I'd been over abusing the chips, now I think they might have been ok.

I'll post some off to David Monday for him to try.

JVR · « **Reply #43 on:** October 22, 2012, 09:12:47 am »

Check P208 of the 883 datasheet, did you do anything with the LVP bit?

the 16F88X's are picky to get working, so make sure you give it proper 5V, decoupled, and leave the programming utility alone, program directly from MPLAB.

Also, test the programmer with another micro, that will verify that it is not blown. As mine (7yrs old) had blown a mosfet or two during its life.

Simon · « **Reply #44 on:** October 22, 2012, 09:15:50 am »

I've ordered a pickit3 to double verify with as i figure a backup won't hurt.

Thing is this worked fine first few goes, then suddenly stopped working. Yes I should try a different chip check it works but i also had it with some 16F88 chips.

I've done nothing to the LVP bit, is that low voltage programming ? this is disabled in the project settings. I am using mikroC so cannot program from MPLAB, I use the programmers own software, why shouldn't I ?

Simon · « **Reply #45 on:** October 22, 2012, 09:31:32 am »

Oh let me guess the pickit3 does not have it's own software - great !!!! so how do I use it as a standalone programmer ? or are microchip going microsoft and trying to lock us into THEIR WAY of doing it ?

JVR · « **Reply #46 on:** October 22, 2012, 10:05:21 am »

There is a standalone interface for the PK3, works exactly the same, just difficult to find on their site, I found it via the forums. Don't ever use it though.

LVP is low voltage programming yes, can be a proper ballache. I'd still say, power the chip from an external supply, put a 10 from MCLR to Vdd, shorten the leads as much as possible, and connect the PK directly to the machine, not via a HUB.

Also, as test, put the PK2 into UART mode and do a loopback test, let us know if this works. And, if you have not done it yet, shut down (not reboot) the PC, and try again.

Simon · « **Reply #47 on:** October 22, 2012, 10:08:38 am »

So how can I otherwise use the programmer without the standalone interface, can i use MPLAB to run the programmer with "external" hex files. What is wrong with the standalone software ? I had no problems on the pickit2

I've not changed any settings and it worked before so I'm not sure why the LVP should be causing a problem.

How do you mean do a loopback test with the pickit2 ?

poorchava · « **Reply #48 on:** October 22, 2012, 10:21:47 am »

Don't power stuff from pickit. It's power supply is kinda crappy.

I remember, that on some occasion i was using PK2 to program & debug dsPIC30F5013 (utter crap, that chip, btw). It turned out that when high speed clock was set, the pic would draw a lot of current during startup and the voltage was falling, which would cause the chip to reset. And the chip wouldn't verify ok. Just gave it external power supply and it worked ok (debugger-wise, 30f5013 remained a total shit :/ drawing like 200-350mA @ 5V)

Simon · « **Reply #49 on:** October 22, 2012, 10:23:38 am »

maybe I should put a bypass cap in too! where does it end ? but this all worked fine the other day unless the power section has blown, but then it wouldn't work when on the breadboard and powered either.

JVR · « **Reply #50 on:** October 22, 2012, 10:23:48 am »

No, what I meant with ''Dont Ever use it though'' is that I dont use it. You can use mplab with external hex files, but it is going to take a lot longer.

Look at the PK2 manual, it has a USB_UART mode, IIRC those use the PGD/PGC pins, so checking if it will work in UART mode with a loopback cable will help assess if the PK is operational.

Still, shut down, reboot, plug directly into PC <- Do those first

Simon · « **Reply #51 on:** October 22, 2012, 10:24:42 am »

Quote from: JVR on October 22, 2012, 10:23:48 am

No, what I meant with ''Dont Ever use it though'' is that I dont use it. You can use mplab with external hex files, but it is going to take a lot longer.

Look at the PK2 manual, it has a USB_UART mode, IIRC those use the PGD/PGC pins, so checking if it will work in UART mode with a loopback cable will help assess if the PK is operational.

Still, shut down, reboot, plug directly into PC <- Do those first

ok

JVR · « **Reply #52 on:** October 22, 2012, 10:25:41 am »

Quote from: Simon on October 22, 2012, 10:23:38 am

maybe I should put a bypass cap in too! where does it end ? but this all worked fine the other day unless the power section has blown, but then it wouldn't work when on the breadboard and powered either.

Remember, the PK is an ICSP programmer, not a Stand Alone programmer. It expects to device to be in a properly configured circuit, bypassed, clamped etc etc

Simon · « **Reply #53 on:** October 22, 2012, 10:52:59 am »

well it is a pity they don't specify the expected circuit environment in the manual.

JVR · « **Reply #54 on:** October 22, 2012, 10:58:34 am »

Quote from: Simon on October 22, 2012, 10:52:59 am

well it is a pity they don't specify the expected circuit environment in the manual.

True, but most of the datasheets have a minimum connection pic in them, you'd need at least that. MCHP is not known for epic documentation, try doing a USB PIC32 design, loads of connections and cap placements are very opaque.

Is it working yet?

Simon · « **Reply #55 on:** October 22, 2012, 10:59:47 am »

I can't check till I get home, in-fact probably not until tomorrow night, so storing up all of the tips for a blast tomorrow night

.

JVR · « **Reply #56 on:** October 22, 2012, 11:03:45 am »

Your going to have a long night

Let us know

Simon · « **Reply #57 on:** October 22, 2012, 11:21:07 am »

will do

deephaven · « **Reply #58 on:** October 22, 2012, 11:38:25 am »

I think I might have a possible answer for you.

There is an issue on the PIC16F883 where programming will often fail if RB3 is not pulled down during programming.

This is described in the errata document. It is highly recommended to check for any errata data on Microchip (and probably other manufacturers!).

Simon · « **Reply #59 on:** October 22, 2012, 11:40:25 am »

Thanks, I'll give that a go too.

JVR · « **Reply #60 on:** October 22, 2012, 02:35:08 pm »

Quote from: deephaven on October 22, 2012, 11:38:25 am

I think I might have a possible answer for you.

There is an issue on the PIC16F883 where programming will often fail if RB3 is not pulled down during programming.

This is described in the errata document. It is highly recommended to check for any errata data on Microchip (and probably other manufacturers!).

Are you kidding me?

Simon, try this first. RB3 was the LVP input on the older F877 silicon, they probably did not remove all the links. FAIL

Simon · « **Reply #61 on:** October 22, 2012, 02:39:09 pm »

so who do I sue for charges at £15/h of my time wasted ?

I am amazed at this, does this really mean that RB3 can't be used for much if the pic is to be programmed in situ ? soon I'll be going atmel !

deephaven · « **Reply #62 on:** October 22, 2012, 03:15:43 pm »

Quote from: Simon on October 22, 2012, 02:39:09 pm

so who do I sue for charges at £15/h of my time wasted ?

I am amazed at this, does this really mean that RB3 can't be used for much if the pic is to be programmed in situ ? soon I'll be going atmel !

Well, I was fortunate in my design that I happen to be using RB3 as a switch input, so I just had to remember to make sure the switch was on when programming the thing.

I haven't used any Atmel parts for a long time, maybe someone that has can comment on whether or not they have erratas to the same extent that Microchip does.

Looking up erratas is just part of my procedure now when I'm thinking of incorporating a different chip.

Simon · « **Reply #63 on:** October 22, 2012, 03:39:45 pm »

To be honest if all current chips out there have this defect it should be noted on the datasheet, not a seperate document.

Simon · « **Reply #64 on:** October 22, 2012, 08:22:37 pm »

well programming completed and verification checked out. Thank you for all your help guys, I'll be trying it out tomorrow now so fingers crossed and hopefully the pickit3 is a nice addition

JVR · « **Reply #65 on:** October 23, 2012, 06:21:56 am »

Great news

Really cant believe they stuffed the silicon that badly. Just shows that the 88X series was not a new design, merely a slight facelift from the 8XX series

Simon · « **Reply #66 on:** October 23, 2012, 11:47:18 am »

I fail to see the need for so many pic parts to be honest. after most pin numbers, clock speeds and number of periferals (linked to pin number) are taken care of how many variants does that leave ?

chach123 · « **Reply #67 on:** October 23, 2012, 05:02:52 pm »

hello there,
what where u mentioning of pic progremming doesn't work well ?
well i'm not that educated , but u know what ,
once, when i programmed a pic , i have kept programming it while LVP (low Voltage programing ) option ticked, ( it was default

) , and i kept getting similar response from pic as u getting now , after deselect LVP option, then programing happened correctly... .
that option is there, where u select Osc mode, RC,XC,HS such ...
i don't know if u experience this case,
just mentioned,

bye bye

Simon · « **Reply #68 on:** October 23, 2012, 05:04:37 pm »

Yes i had this problem on another project so learn there. It seems there is a similar problem here but it relates to a "bug" in the chip and i need to ground a pin when I flash it.

poorchava · « **Reply #69 on:** October 25, 2012, 11:57:36 am »

I think the reason for the multitude of Microchip controllers comes from customer needs. It's not always that company orders an ASIC and this ASIC is customer specific. I mean the development was driven by customer needs, but is not customer exclusive. This means that company develops a chip based on needs of particular customer, but the chip gets included in company portfolio and is available to public. This means that customer does not need to cover full costs of development, because the semiconductor company can make profit on that chip from other clients too.

This can be easily seen on the example of Toshiba, AllegroMicro, ICHaus.

This is a common situation, but I don't know for sure whether this applies to Microchip - those are only my suspicions.

btw. Microchip reuses silicon in other cases too. At one point they apparently made some very severe fuckup in either design or fabrication of pic18k[something] which caused mcu to be disfunctional to a degree even Microchip cannot accept. But some part of the chip together with USB module were ok, so they made some quick hack and marketed those as usb-uart bridges. I think someone at some forum pointed out the fact, that usb bridge when connected to a programmer through some supposedly unused pins identifies itself as pic18k series

Simon · « **Reply #70 on:** October 25, 2012, 12:00:27 pm »

They do that on processors too, that why you have so many speeds.

They still have a stupidly large range of pics all so similar that it don't always make sense.


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: device failure on PICKIT2 (Read 22790 times)

Share me