PICkit 3 still seems dodgy

[ThorTheNorseman]

I've had no end of trouble with PICkit 3 and MPLAB X. The thing won't even program a simple PIC16F785 out of the box. I had to change the voltage to 4.875 V before that worked, and this is with the latest software. PIC32 is proving to be a nightmare, with a lovely mixture of "Failed to get device ID", "The PICkit 3 is missing a memory object" errors (when the thing was finally detected), the occasional successful flashing, and the apparent bricking of two chips. This on two separate veroboards on which three separate PIC32MX250F128B's were fitted, with proper SMD adapters and the requisite minimum components.

Microchip's support also seems less than stellar. Support tickets go unanswered, and if I call their Europe support during working hours, I get a voice mail, on which I leave a message without getting a call back.

MPLAB X is fine and dandy in terms of working code projects. It's NetBeans, after all, though I'm slightly annoyed about them having disguised GCC as XC32 and stripped it down in order to sell you the Pro version. What sort of garbage is that? When it comes to control of the PICkit 3? In MPLAB 8, you had nice things like power on/off, erase, blank check and verify conveniently available in a menu. Where has all that nice stuff gone in the X version? I've switched to Mac OS X since I last purchased a programmer from Microchip, and was pleased to learn that MPLAB was going to be available on the Mac, but this isn't even the same product anymore.

I've most certainly had a negative experience. What are your experiences with the PICkit 3 and MPLAB X, particularly in combination with PIC32 chips? I have traditionally had three reasons for sticking to Microchip: user friendly, excellent documentation, nice IDE. Now all I seem to be left with is the documentation. What on earth are they smoking over there?!

[Rufus]

I've had no end of trouble with PICkit 3 and MPLAB X.

Everything USB seems to be very flaky in MPLAB X, their cross platform USB driver model/interface is obviously all new for MPLAB X.

People are reporting that ICD3 and real ICE are working better in the recent 2.0 release.

[gocemk]

I'm using the PICkit3 for well over a month now on Win7 64-bit and MPLABX v1.95 on an EasyPIC 7 board (as an external programmer) and various  PIC12/16/18 chips without any major problems. When i upgraded to MPLABX v2.00, (the pickit's firmware was also updated to latest) the debugging from MPLABX stopped working. It kept complaining about setting the right configuration bits (Single Supply ICSP bit). No matter how the bit was set, the debugging didn't work. Reverting back to MPLABX 1.95 solved the problem.( I didn't downgraded the firmware).

I also have an EasyPIC Fusion board with PIC32MX795F512L on board , but i haven't tried the pickit on that board yet. And now that you mentioned the bricking of PIC32 chips i am hesitant to do so, because the price of the mcu boards for the Fusion are around ~50$ and i really don't want to get burned.

If i decide to try it on the pic32, i'll let you know about the results.

[dannyf]

I am a die-hard pickit2 user.

[true]

I've had no end of trouble with PICkit 3 and MPLAB X. The thing won't even program a simple PIC16F785 out of the box. I had to change the voltage to 4.875 V before that worked, and this is with the latest software. PIC32 is proving to be a nightmare, with a lovely mixture of "Failed to get device ID", "The PICkit 3 is missing a memory object" errors (when the thing was finally detected), the occasional successful flashing, and the apparent bricking of two chips. This on two separate veroboards on which three separate PIC32MX250F128B's were fitted, with proper SMD adapters and the requisite minimum components.

Pretty hard to brick a PIC32; I've always been able to recover them. But if your tool isn't working they may appear to be that way :/ Sorry, I can't offer much there. One friend who uses Pickit3 hasn't had problems. I use ICD3.

though I'm slightly annoyed about them having disguised GCC as XC32 and stripped it down in order to sell you the Pro version. What sort of garbage is that?

I agree. I wrote and compiled some medicine if you need it. There is also some unfinished code on the internet that does work fine for XC32.

People are reporting that ICD3 and real ICE are working better in the recent 2.0 release.

And I _just_ updated to 1.95... bah. My ICD3 was somewhat flaky but did work so I'm glad to hear it might be working better.

[hans]

My experence with MPLAB X is in general dodgy IDE. The only thing I read on the Microchip forums "if you are not using Linux or Mac in your workflow, use MPLAB IDE". In short, MPLAB X:
- It has been sooooo slow, from day 1. This inherent to MPLAB X, because it uses netbeans crap. I have got the same hatred towards Eclipse, they both run in a Java runtime environment.
On my laptop (an C2D system, 4GB RAM, 128GB SSD), I boot MPLAB X, half a minute later there finally is a IDE window. CPU was utilized 100% all the time.
On my PC (a new i5 system with 16GB RAM, 256GB SSDs) I boot MPLAB X, it still takes 20 seconds to boot and 100% CPU utilization.
Anytime the IDE goes "parsing projects", it becomes unresponsive for a second or 2.
If I "Clean project" on laptop machine, it becomes unreponsive for a second or 3.
People recommended me to delete/replace the "xlcm.exe" because even in the FREE version it is contacting the Microchip server on every file being compiled. This "contact" takes like 2-3 seconds if you're unlucky. So a medium sized project with 20 files takes like a minute extra (!) to compile.
On my PC, after replacing the xlcm, enabling parallel compile, that same project takes 4 seconds to clean&build.

Why isn't there a decent IDE written in Qt these days? Qt runs on almost everything , should be possible..

- MPLAB X uses so much memory. Because it runs Java.

- PICKIT3 & PICKIT2 support is shabby. It's not a case of it either works or it doesn't work. It's mystifying, unpredictable, MPLAB X crashes randomly, undocumented errors (like, I don't give a toss that MPLAB X misses a memory object, I want my debugger to debug this chip).

I usually end up using the standalone app with my PICKIT2, and only when I really have to start the debugger. Or go back to MPLAB IDe. MPLAB X & PK2 support also has many bugs, but they say it's not their top priority to fix the support (because PK2 is old..).

I only have had problems with PICKIT3 and PIC24FJ64GC006 (one of the very latest ones) in MPLAB X. Never got it to work. MPLAB IDE? Some issues, but it works. The debugger glitches out every now and then though, which is extremely annoying.
I have got a feeling I made a step backwards whenever I'm using the PK3 in comparison to PK2 (except for extended device support).

In my opinion Microchip should really try harder and fix their tools. I think their range of 16-bit & 32-bit micro's can be really interesting, there is a lot of "content" out there to be sourced from, but it's too bad there is so much toolset (especially on their software side) crap going on.

[dannyf]

That whole mplab x team should be banned from ever touching any piece of code. It took them years to get a half-baked buggy product to market.

Just total incompetency.

[dannyf]

I have got a feeling I made a step backwards whenever I'm using the PK3 in comparison to PK2 (except for extended device support)

Agreed.

I never understood their rationale for abandoning pk2 in favor of a decidedly inferior product (pk3).

[ThorTheNorseman]

I'm having the weird experience of having this work more reliably on a breadboard than on a veroboard... and the veroboard checked out electrically, I measured everything carefully. I'm very confused. Still, I'm not terribly impressed.

[jaxbird]

I originally bought a PICkit3 clone and I thought there was something wrong with it, so I also bought the original, however the original is just as bad as the clone 

Recently I did a small project using a 16F684, it didn't work at all with PICkit3, I thought the mcu had gone bad or something until I found my old PICkit2, then everything was just fine.

I often find that the PICkit3 just stops working, then I need to unplug it, plug it back in and restart MPLABX to get it back.

For MPLABX, I can live with that it's a bit slow and consumes an enormous amount of memory, but I really hate the times on larger projects when it suddenly refuses to compile anymore and only gives some strange undocumented error saying please contact Microchip  I've found the only way to get it back to working is to move the code around a bit (without making any actual changes) then it starts working again.

I wish they would spend a few month just bashing bugs.

[senso]

Even the pickit3 Standalone program is a nice piece of code crap..
Tried to program a couple of pic16f something for a friend, lol nope, only exceptions and more exceptions followed by a couple freezes, I'm always wondering if it is my computer or if pickit3 is as crappy as it seems 

[andersm]

People recommended me to delete/replace the "xlcm.exe" because even in the FREE version it is contacting the Microchip server on every file being compiled. This "contact" takes like 2-3 seconds if you're unlucky. So a medium sized project with 20 files takes like a minute extra (!) to compile.

That should be fixed in the latest versions of the compilers.

[lapm]

People recommended me to delete/replace the "xlcm.exe" because even in the FREE version it is contacting the Microchip server on every file being compiled. This "contact" takes like 2-3 seconds if you're unlucky. So a medium sized project with 20 files takes like a minute extra (!) to compile.

That should be fixed in the latest versions of the compilers.

Im more curious why they tough its good idea in first place to add call home functionality.

[Rufus]

Im more curious why they tough its good idea in first place to add call home functionality.

It doesn't 'call home'. It supports floating licensing from a network license server and due to some screw up it tries to find a license server when it doesn't need to or isn't supposed to.

[senso]

And what is the need to use HID mode for the programmer, I suspect that almost all the problems are related to retarded drivers in windows and choosing hid mode for what could be using the serial emulation thingy.

[andersm]

And what is the need to use HID mode for the programmer, I suspect that almost all the problems are related to retarded drivers in windows and choosing hid mode for what could be using the serial emulation thingy.

AFAIK, Windows has only had CDC support built-in starting with Vista, plus the OS is kind of weird in how it handles COM ports. HID basically works on anything that supports USB.

[senso]

With the problem that it doesn't always works as it should 

[eurofox]

With the problem that it doesn't always works as it should 

You can send an email to : bill.gates@microsoft.com

 

[JTR]

Suggesting a virtual serial port over HID for reliability purposes is probably the dumbest thing I have ever read on this forum. 

[senso]

Re-read my post again, or maybe it was not clear, what I said is that choosing HID is also not a great way of communication, due to the great windows drivers, and the fact that windows always tries to connect the pickit as a freaking keyboard.

[hli]

I had to change the voltage to 4.875 V before that worked, and this is with the latest software.

I think these problems stem from a misunderstanding of what this setting means. AFAIK it defines the voltage the PicKit expects to see as target voltage. But when powered by USB, you basically never get 5V as output. First the USB voltage is lower than 5V in most cases, and then there is the circuitry in the PK3 taking its toll. That's why setting 5V here won't work most of the time (though it should when powering the target externally).

[mrflibble]

Suggesting a virtual serial port over HID for reliability purposes is probably the dumbest thing I have ever read on this forum. 

I take it you're fairly new to the forum then? 

[JTR]

Suggesting a virtual serial port over HID for reliability purposes is probably the dumbest thing I have ever read on this forum. 

I take it you're fairly new to the forum then? 

Nice quip, me likes and I can see where you are coming from. I mean I did have the misfortune to read the C Vs ASM thread. 

However I spend all day, every day working with (writing firmware for) both HID and CDC devices so I have my perspective... 

[MartinP]

I also just discovered that I need to set the Power to 4.5 V instead of 5 V when using a PICKIT3 with a custom card to avoid the error "Failed to get Device Id.".  The Status shows around 4.66 V, so I assume the card is pulling the voltage down.  I never experienced these type of problems with the PICKIT2 before.

[ggchab]

I had a similar problem with my PICkit 3 connected on an old desktop computer (to program a 12F1822 powered by the PICKit). I had to lower a bit the voltage in the power settings. The error message said this could be be due to the USB port delivering a bit less than 5V. The same PICkit 3 is working perfectly on my recent laptop.

[fonak]

Hi
My problem with pickit3 is similar to MartinP. In my case the problem was solved by the connection of the additional 10uF cap to the Vcc line of the PIC16F18855 and lower voltage to 4.5V. In my opinion pickit3 is the least stable and slowest programmer I have.

In the last time I built a programmer based on NSDSP (PIC16F1454 + GTL2003) and I'am very happy. The programming speed is at least several times faster than pickit3.

[Siwastaja]

What kind of engineer makes that kind of design anyway?

Under-voltage lockouts are normally used when there is something to be protected against voltage too low - and set to the level so that normal operation is possible.

But what idiot takes the USB 5V supply and designs extra logic that prevents everything from working when the voltage is both within the USB specifications and within the area where everything would just work fine without artificial errors.

The fact that it's adjustable doesn't cut it - in fact, it only highlights the stupidity. They provide a broken-by-design product by default, but let the user configure it to work, using a misleadingly named control. 

In a sane design, there either wouldn't be such a feature at all, or it would be named: "expected minimum voltage", and it would default to the lowest value which still guarantees succesful programming.

[jaromir]

"Powering from programmer" feature is really bad done in PK3 (the internal adjustable power supply is too weak, doesn't work well when USB cable is crappy, USB host provides too low voltage or both) and honestly I don't what is its purpose on programmer designed to serve as in-circuit programmer. I never use it and have no problems with PK3.

As well as I don't know what is the purpose of exhumation of three years old thread. Please, look at thread context before replying with as useful reply as "me too".

[KL27x]

You can put a DC boost circuit in there to get 5V. Just cut the power trace coming off the USB connector. Patch the Vusb to the input of your boost circuit. Then put the 5V output back to the PK3 Vsupply trace you cut. And put a low dropout shottky across the broken trace as a bypass/rectifier.

This is something I have done with PK2 since forever. I don't use a laptop much, anymore, but in those days it was necessary with mine. Some of the older chips need at least 4.5V to erase, at all. I have this on my PK3, too, before I even know it had this problem. (Integrated into PCB for charging and powering from Li Ion battery.)

 

 

[Free_WiFi]

https://reviahh.wordpress.com/2016/01/31/making-a-pickit-3-clone
Try to make this one by yourself,it's working fine to me

[Free_WiFi]

or this one
https://reviahh.wordpress.com/2017/10/