EEVblog #841 - Microchip MPLAB X PICkit 3 Woes

[Howardlong]

I use a PICKIT3 regularly, and it just works.

So do I, but one thing I am sure of regarding experiencing frustration with the PK3 (and pretty much any other hardware debugger) is that there are those who have, and those who will.

[jaromir]

I took one of my three PicKit3 debuggers and did a bit of torture to it.
The only way how to get it into funky state was via PK3 application (Tools->Download PicKit operating system), as seen on ss1 and ss2 attached to this post.
Then, IPE was really unable to connect to PK3, as seen on ss4.
I disconnected PK3, pushed button on it, reconnected and IPE downloaded correct firmware as expected. I noticed that Dave's error message while connecting IPE to "wrong" firmware was different to what I got.

Did this a few times, including reverting to MPLAB mode via PK3 application and I kept the PK3 busy for around half of hour with no problems whatsoever - except of failing to close the PK3 application (access to file denied). I'm pretty sure it worked on this machine before, perhaps some bloody windows update?

By the way this is the first time I switched to non-MPLAB mode or used button to revert PK3 to its default state. I've never used that before and myself and my colleagues (including non-technical users) are using PK3 really a lot.

[mux]

I use a PICKIT3 regularly, and it just works.

So do I, but one thing I am sure of regarding experiencing frustration with the PK3 (and pretty much any other hardware debugger) is that there are those who have, and those who will.

Once anything Microchip doesn't work, it's been an endless struggle to get it working again. This has to do with a bunch of things, some of which are conscious design decisions and some of which are just legacy things:
- Probably by far the most important thing: Microchip is really fucking bad with their documentation. Like, it's one of the worst companies in this respect and only recently has it become significantly better. They used to have the 'locked behind glass doors' philosophy, where you had to become an authorized whatever to get access to full datasheets/manuals and the like. This also meant that support on forums was very limited. And they have a million different chips, so docs are important. A lot of upgrades were blind, especially IDE/programmer updates, meaning you had no comprehensive changelogs and no guide to tell you what has changed, how to upgrade and what to look out for. Errata were very late. Other companies have this problem too (see Atmel with their XMEGA introduction), but Microchip is one of the worst offenders. It's only really annoying when you consider that everything non-microcontroller that Microchip made had awesome, detailed datasheets and appnotes.
- As already stated many times before, PICKit uses an MCU that was just too small by design to fit in programming code for all parts. So you have to reprogram its flash memory every time, and for some people it gives out after a year or two (couple thousand P/E cycles).
- Microchip by design uses dozens of different programming protocols, whereas most competitors have unified programming interfaces even across chip series, which means more points of failure
- Microchip changed their mind on a few interfaces, most importantly on USB payload sizes, which fucks up a lot of version boundaries (requiring you to use the older version of programming software to flash a newer firmware which *is* compatible with the next version)
- Similarly, a bunch of programmers and software packages are simply not tested with all versions of windows, which leads to stuff like the recent issues with Windows 8 and 10 (which, by the way, haven't been fixed after 2 years)
- Microchip has a few programmers (among which PK2 and 3) that don't have any built-in mode switching. As to why - there seems to be no technical reason, they just didn't program it. Which means you can have it in the wrong mode and just not be able to use it. Yeah, it has a button but you don't have access to that in a remote ICSP situation (e.g. in a climate controlled chamber or anechoic chamber) - meaning those tools aren't even useful for prototyping.
- the list goes on, this is the stuff I'm familiar with + what came up with the video.

Combine bad design decisions, changing Windows APIs/requirements and poor documentation and you get a perfect legacy horror story. It's the same kind of situation you get with old LPKF milling routers that are essentially worthless without the accompanying 25 year old Windows 3.1 computer with strange ISA plug-in card. And that milling machine came out in 2002

And you haven't even started me on PICBASIC...

This also very much explains why a lot of people say 'well I bought the Microchip XX and it worked just fine out of the box, no problems whatsoever' - yeah, it does when it first comes out, because all the duct tape has been applied in such a way to just barely work on the current version of Windows with the current product portfolio. But just you wait until the patching begins ;-)

Keep in mind that these stories are also slightly fueled by many lost weeks to Microchip tools.

[LazyJack]

I just can't wait Microchip buying Atmel and use MPlab on AVR.

[EEVblog]

I just can't wait Microchip buying Atmel and use MPlab on AVR.

They did it a couple of years back:

[EEVblog]

   Boy, was this timely for me. Just today I've played with my first bare metal AVR.
Getting SPI up. Hours to figure out I need to config all the SPI functionality first,
THEN set the SPE enable bit. Then everything was stupidity: "!" NOT, instead of "|" OR
in a few places, and the wrong SCK edge selected. Somehow it took most of the day.

Careful you don't brick your AVR chip by playing with those config bits!

[Brumby]

But it does seem that the only time this particular device gets mentioned is when it goes wrong, and I think that's misleading. It's not that bad!

You must be young.  This is the way of the world for most things  - PICkits included.

[Psi]

Need to rename the video "A typical day in the life of a PIC software engineer"
 

[philn]

Hey Dave,

About your new product: I think it would be far more interesting if you showed what you're actually developing/working on instead of always keeping it a secret. It's so often that I hear you saying "I'm working on this, I'm doing that... but I can't talk about it." Why is that? I think that's what a vlog should actually be about, and what the term "video blog" implies, a video web log of your daily life as an engineer.

[Supercharged]

Hey Dave,

About your new product: I think it would be far more interesting if you showed what you're actually developing/working on instead of always keeping it a secret. It's so often that I hear you saying "I'm working on this, I'm doing that... but I can't talk about it." Why is that? I think that's what a vlog should actually be about, and what the term "video blog" implies, a video web log of your daily life as an engineer.

He said he is developing it with another company so maybe they don't want him to talk about it

[ercapoccia]

Just tried my PicKit3 i got from banggood with MPLAB IPE and it worked like a charm.

[roli]

This is why I love working with ARMs. At least the ARM SWD debugging interface is pretty standard. I've been programming my Nordic nrf51 chips with my STM 32f4 discovery board (that includes the STLink debugger) without any issues. I did that because I can get an STM board for 10€ while the Nordic dev kit costs around 80€. Yes the Nordic dev kit has a debugger from Segger but as a student I really have no need for that.

[Alexei.Polkhanov]

It looks like most of people who have problems did not UNINSTALL previous versions of all Microchip software from their workstations prior to installing latest version. As simple as that.

[c4757p]

Yes, as simple as doing something the installer should have figured out for itself. If running multiple versions simultaneous doesn't work, the installer should refuse to do it.

I've yet to see anyone give an explanation that doesn't translate to "Microchip developers are incompetent".

[VinzC]

I completely understand Dave's rant here. That reminds me of other struggling (long) moments and I also have gone through such rants over and over. This journey honestly should remind designers, *all* of them — including us — how and why retro-compatibility matters. Clearly Microchip suck at it one way or another.

We're too much used to things being temporary and ditching them as we buy anew. Of course not every industry behaves carelessly like this and there are who care for long lasting products. There should be no such struggle through upgrading and no one should accept that. This is not evolution, this is slavery. Maybe that implies a change of attitude about obsolescence...

[TheCharels]

After watching the video again I would like to say that Dave has as much if not more responsibility for the problems encountered than Microchip. Granted that the PICkit3 has multiple opportunities to cause problems but this rant seems to me to be more shrill with regard to Microchips contribution to his problems than his own past actions.

This is like blaming the hole in the wall on how Browning makes their 12 bores but not bothering to mention you forgot you stored it loaded.

It's a lot of fun to watch Dave whinge on about the marginal tools giant companies foist on their customers.

Come on Dave you set yourself up for this problem.

[artag]

Dave does like to rant .. but badly documented introductory tools deserve it. How would you have had him handle it ?

[MT]

Impressive that you have to use a separate tool to put it in the right "mode" so your other tool can talk to it. How could they afford bloody Atmel if they can't even afford developers who can figure out how to put that functionality directly into MPLAB?

That's similar to the question: the meaning of life!
The 2 sec of silence just before and the following ahhhhhhhhhh moment in the video was great!
I have had numerous of those!

[Brumby]

Hey Dave,

About your new product: I think it would be far more interesting if you showed what you're actually developing/working on instead of always keeping it a secret. It's so often that I hear you saying "I'm working on this, I'm doing that... but I can't talk about it." Why is that? I think that's what a vlog should actually be about, and what the term "video blog" implies, a video web log of your daily life as an engineer.

Some phrases for you:

- Commercial-in-confidence
- Industrial secret
- Non-disclosure agreement

These are just a few pointers to one of the most important rules of product development - not letting your competition know what you're working on!!  There can be multiple reasons for this - the first is the absolute need for confidentiality if you are working on a development for a patent application.  The second is to get your product into the market before anyone else.  Being first to market means you establish your product as the leader and start getting sales while your competitors play 'catch up'.

Then there's the possibility of military applications.  Say no more.

As it is, if Dave says he "can't talk about it" and still presents a blog, you can rest assured that those details of any given project he might be working on are not required for the objective of the blog.  Yes, it might well be a really interesting subject, but they are off limits for a public blog.  Also, don't think asking him or visiting his lab will get you any info either.  The reasons for him not sharing publicly will likely cover those situations as well.


The bottom line is that if Dave doesn't tell you something - it's because it's not his place to say.

As for:

a video web log of your daily life as an engineer.

Please.  Let's not get into this argument.  But I will tell you now that if Dave ever turns into a Kardashian - I'm outta here!!

[pciebiera]

Holding the button down while connecting the PK3's USB will cause the bootloader to trigger.
You don't really need the 3.10 stand alone tool.

[Monkeh]

Holding the button down while connecting the PK3's USB will cause the bootloader to trigger.
You don't really need the 3.10 stand alone tool.

And you shouldn't need to do that much to get the damned thing to talk with the current software which is meant to use it.

[nixfu]

Well, I had been considering trying out PIC at some point....but I think I will stick with AVR and ARM programming.

I want nothing of that mess of a product stack.

[FrankBuss]

Well, I had been considering trying out PIC at some point....but I think I will stick with AVR and ARM programming.

Depends on your product, but you should think about it again. There is a reason that there are PICs in many commercial products. I don't know if this is official company policy, but looks like you can still get any PIC ever produced, e.g. PIC12C508, introduced 20 years ago (says archive.org). And usually for the same performance they are cheaper than competitors, and reasonable low power (but I think something like the MSP430 is better for extreme low power, but more expensive). And as mentioned before, once it works, it works. The chips itself are very good (albeit the architecture of the peripherals are strange sometimes), it is just the development environment and documentation which could be better.

[EEVblog]

Holding the button down while connecting the PK3's USB will cause the bootloader to trigger.
You don't really need the 3.10 stand alone tool.

Something that's not even mentioned in the PICkit3 user guide IIRC.
And even then you have to know you need to do this in the first place, and that wasn't the least bit obvious.
The point is you shouldn't even have to do this.

[EEVblog]

After watching the video again I would like to say that Dave has as much if not more responsibility for the problems encountered than Microchip. Granted that the PICkit3 has multiple opportunities to cause problems but this rant seems to me to be more shrill with regard to Microchips contribution to his problems than his own past actions.

Rubbish, the tool should have worked. Or handled it better.

Come on Dave you set yourself up for this problem.

It's not like I hacked the tool in the past, I simply used it as it was intended to be used, with their tool. Then when I go to use it a few years later it doesn't work, and it's completely non-obvious why that is the case.
How is that my fault?