EEVblog #841 - Microchip MPLAB X PICkit 3 Woes - Page 1
Forum section: electronics / general

author: EEVblog
author_rank: Unknown
timestamp: January 18, 2016, 10:00:28 pm
content: Dave and David2 battle to get an old Microchip PICkit 3 working with MPLAB X talking to Dave's new product.A tale of misery, rabbit holes, Murphy, facepalms, and ultimately success. You get a warts and all journey.A good example of how a tool that should have just worked, turned into a nightmare due to some bad luck and poor tool protocol and mode compatibility.

author: DarkStar
author_rank: Contributor
timestamp: January 18, 2016, 10:41:10 pm
content: Can't wait to hear about this "new product!"

author: hamdi.tn
author_rank: Frequent Contributor
timestamp: January 18, 2016, 10:48:41 pm
content: Typical struggle to make things workAt the same time i was trying to use pickit 2 after a year not used with 16F1824 and i couldn't cause not supported by Pk2.i used both pk2 and pk3 i didn't like the pk3 at all.for the problem you had , i had that too and i used the standalone application with pk3 (the one you used at the end of your the video) and not the API it was more reliable, sadly it crash for you, it could be an other version of the standalone app i didn't used pk3 for 2 years now. and if i remember correctly the one i used is a beta version i found in the microchip forum and not in the official product page.

author: Herrbert
author_rank: Newbie
timestamp: January 18, 2016, 11:03:51 pm
content: Avira prevented me from programming my cronusmax joypad adapter, it got recognized like yours. The programming just failed. Get rid of it for a second, reinstall it later if you need.The guy who made the device was confused about this, too.It worked month before with an older updater.

author: c4757p
author_rank: Super Contributor
timestamp: January 18, 2016, 11:08:48 pm
content: Impressive that you have to use a separate tool to put it in the right "mode" so yourothertool 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?

author: EEVblog
author_rank: Unknown
timestamp: January 18, 2016, 11:09:48 pm
content: Quote from: c4757p on January 18, 2016, 11:08:48 pmYup, it's pretty retarded.

author: jaromir
author_rank: Unknown
timestamp: January 18, 2016, 11:18:19 pm
content: I assume the standalone PK3 application (used revert deaf PK3 into MPLAB mode) has to be used to put it into "non-MPLAB mode". AFAIK MPLABX IDE/IPE has no means to put the PK3 out of MPLAB mode.No idea how Dave's PK3 got into non-MPLAB mode (=has different firmware than MPLABX expects).

author: hamdi.tn
author_rank: Frequent Contributor
timestamp: January 18, 2016, 11:35:16 pm
content: Quote from: jaromir on January 18, 2016, 11:18:19 pmsince i don't own pk3 anymore i can't test that, but i vaguely remember that it does. since it have to update its firmware everytime you change target family , it must have a way to change mode too.check out this link, they talk about a "reset" option in the project property pane.http://www.microchip.com/forums/m762080.aspx

author: robertbaruch
author_rank: Regular Contributor
timestamp: January 18, 2016, 11:45:20 pm
content: About your sucky downloads, I had the exact same symptoms downloading other large programs (in my case, Mathematica). It would download a bit, then slow, then stop. Over and over. And I'm in Silicon Valley! Eventually I found out it was Kaspersky Antivirus that was causing this to happen, in addition to a bunch of other symptoms like just opening a folder and nothing happening for a few minutes until suddenly it pops up.I switched to Avast and suddenly all my downloads work fine, no weird nonresponsive folders.So maybe (cross fingers) turn off your antivirus to see what happens?

author: TheCharels
author_rank: Contributor
timestamp: January 18, 2016, 11:59:23 pm
content: Dave,You ain't done yet.When the PICkit3 GUI tells you the device ID reads as (0) then the ICD connections to the target are not working correctly.You have still got some hardware debugging to do.But then you know that as I just re-watched the last 8 minutes of your video and now I see a big red over-text at about 35:02 that says your found a hardware issue.

author: piranha32
author_rank: Unknown
timestamp: January 19, 2016, 12:37:35 am
content: Most of the problems must be some kind of Windows fuckery. I downloaded Mac version of MPLABX v3.15, set target to pic32, and... IPE did not work. Eventually MPLABX v1.95 recognized my PICKit3, but only after I switched target device to smaller device (dsPIC32). Uploaded firmware to the programmer, and worked fine. At this point I installed MPLAPX 3.15 again, and it worked with dsPIC32 (PIC32 requires connection to target device). Unfortunately I did not check with smaller devices before downgrading to v1.95, but I have a strong feeling that it was mostly PEBKAC error. I have no PIC processor to connect to, so I can't test communication with the device, but firmware uploads fine, and IPE connects to the programmer without problems.EDIT: MPLABX installers for Mac are not as big as for Windows, but still, 250-350MB took only 2-3 minutes to download from Microchip's website.

author: TheCharels
author_rank: Contributor
timestamp: January 19, 2016, 12:57:04 am
content: In my experience MPLABX v3.20 does not play well with previous version of PICkit3 firmware.The PICkit3 has three kinds of firmware in it.1 - The bootloader. Seems solid, Works with all the GUIs I've needed.2 - OS firmware. This is the problem.The version loaded by MPLABX v3.20 does not play well with some of the previous MPLABX versions or MPLAB v8.92, but none of the IDE show a warning that the "new" OS firmware is not reliable.3 - Target specific programming firmware.This one does not play well when the OS firmware is not the same "vintage" as the target specific firmware.This issue is likely unique to my situation. I have projects that for legacy reasons must be built with MPLAB v8.92 and new projects that build with MPLABX. When I fail to force an OS firmware and target specific programming firmware to update to the "current" version that the MPLAB IDE I am building with then the PICkit3 fails in strange an mysterious ways.A good thing about the PICkit3 is that you do not need the MPLABX driver switcher to use it with MPLABX or MPLAB v8.92. The bad things is that as a debug tool it has problems that Microchip never seems able to fix.

author: FrankBuss
author_rank: Unknown
timestamp: January 19, 2016, 01:07:58 am
content: Congratulation, a day of work what needs a second with an Arduino IDE. Now the Microchip CEO has to make another funny answer videoWould be better if they would fix the thing.I like PICs, but PICkit 3 is terrible. PICkit 2 was fine, no problems with MPLAB. The new MPLABX is bloated and slow (it is based on Netbeans, written in Java, which itself is not that slow, but maybe all the custom Microchip plugins slow it down), and all these PICkit 3 target specific firmware is silly. The programmer itself should be dumb, they should put all the logic into the PC side. Recently I testeda new project I'm developingwith a Lattice FPGA chip, which can be programmed with JTAG, and their programmer just uses a FT2232 chip, so you can build your own programmer easily. Yeah, I don't like the FTDI business practice, bricking fake devices, but they are the market leader and they do all the stuff for you like driver development, which is integrated in the Windows update etc. and you get an easy to use interface for low-level GPIO control, including some interesting high speed FIFO and JTAG modes, and UART.For projects where I don't need the smallest, cheapest microcontroller, these days I just use a modern ARM microcontroller, like the nice LPC family microcontrollers from NXP. It has a USB port with a special boot mode. Just plug it into your PC, it is enumerated as a thumb drive, copy the new firmware to it (which the special boot loader will flash then very fast) and you are done.Everything should be as easy as possible, like with the Arduino or the USB thumb drive firmware update process. Now the question is: Will this get more difficult with Atmel chips and more bug-ridden when Microchip buys Atmel?

author: EEVblog
author_rank: Unknown
timestamp: January 19, 2016, 01:16:11 am
content: Quote from: TheCharels on January 18, 2016, 11:59:23 pmIt was more of a hardware PEBKAC

author: tindel
author_rank: Newbie
timestamp: January 19, 2016, 02:06:07 am
content: Jesus Christ! Nearly 45 fucking minutes of dogging on Microchip. How fucking boring.I certainly don't care for microchip - most practicing engineers agree, I think. I always joke around saying "Microchip parts always work... sorta" or "Microchip parts always work... once you figure out how they work."Microchip has published over and over again that the pickit3 isn't recommended for production programming. Pony up and spend a couple more bucks for the ICD3 - and quit your bitching.New drinking game. Take a drink every time Dave says "Unbelievable"

author: FrankBuss
author_rank: Unknown
timestamp: January 19, 2016, 02:27:10 am
content: Quote from: tindel on January 19, 2016, 02:06:07 amBut it should at least work out of the box, other manufacturers can do it better and even PICkit 2 was better. Lots of people are complaining about it. Imagine a student, trying to work with PICs. She'll give up and use instead an Arduino. Later as a CTO of big$ corp when she decides the next microcontroller for the million parts product: "I'll use Atmel, the software just works, I don't trust Microchip, even if it is a little bit cheaper".

author: rrinker
author_rank: Super Contributor
timestamp: January 19, 2016, 03:26:42 am
content: True - years ago I bought a PICkit 2 starter kit that had the programmer and a small board with a 16F690, and I never had any issues with it, it all just worked out of the box, with multiple compilers - I tried a bunch besides the supplied stuff. Haven't messed with micros much since then - good thing it uses a standard micro-USB, I just pulled it out of the drawer and the cable's gone missing. Recently picked up some Arduino stuff, seem to be heading in that direction now - although I have a huge stash of 16F873 and 16F876 variations - 19 in all, acquired through Dave's most hated method, free samples. A model railroad control board I had been planning to use uses the 873 and with the chip being discontinued, I wanted to have enough to handle my future needs. Now, they just sit in my drawer gathering dust (on the outside of the box - they are in a box, all in anti-stat tubes)

author: c4757p
author_rank: Super Contributor
timestamp: January 19, 2016, 03:30:19 am
content: Quote from: tindel on January 19, 2016, 02:06:07 am"Not recommended for production programming" is an excuse for not working now? Every product should work, you don't sell broken things, period.

author: EEVblog
author_rank: Unknown
timestamp: January 19, 2016, 05:02:23 am
content: Quote from: tindel on January 19, 2016, 02:06:07 amIt was a blow-by-blow account of me solving a real problem with the tool I encountered.If you find it boring, that's fine.QuoteAre you serious?I'm not doing production programming, I simply want to use the tool as intended to talk to a single device in my product.It didn't work, I had every right to bitch.

author: Brumby
author_rank: Unknown
timestamp: January 19, 2016, 05:06:37 am
content: I don't decry Dave for having presented his tortured exercise - as it is very relevant for the state of this segment of the industry AT THIS POINT OF ITS DEVELOPMENT.Having to muck around with prior versions of software as he did is something I would expect from 10 years ago or more.

author: forrestc
author_rank: Unknown
timestamp: January 19, 2016, 06:04:48 am
content: Quote from: Brumby on January 19, 2016, 05:06:37 amI think a big part of this has to do with the fact that when microchip went to MPLABX they switched a lot of stuff from a proprietary USB driver/interface to a more standard one. This required a change in the drivers in windows, and also changes to the firmware on the device itself. Until you get the newer MPLABX drivers running on windows AND the firmware updated in the devices to be compatible with the newer drivers, things just act wonky.BUT... once that is done, and you switch to using MPLABX exclusively these problems seem to go away and things work pretty consistently.I would, however, recommend a ICD3 instead of the PICKit hardware. The ICD3 just seems more stable. I do multi-target work and I have had up to 3 of them attached to a single machine running 3 copies of MPLABX without any major issues.

author: Dinsdale
author_rank: Regular Contributor
timestamp: January 19, 2016, 07:16:28 am
content: 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 "|" ORin a few places, and the wrong SCK edge selected. Somehow it took most of the day.I took a break and your video reminded me that I'm not alone and made me laugh at myself.I've used older versions of MPLABX - mostly OK but I've had my share of weird behaviour.It's really nice just to use vim, gcc, and avrdude. I know exactly what's going on, italways works and I don't have to deal with any ones vision of an "environment".

author: Alexei.Polkhanov
author_rank: Frequent Contributor
timestamp: January 19, 2016, 07:48:09 am
content: ICD3, MSP430 programmer, USB Blaster ... every time I need to connect to another bloody chip I need to spend $75 to $299 on programmer and they all essentially same - USB-to-serial or USB-to-JTAG interface with few tweeks! So much waste, why can't they use same hardware !? I know it never going to happenJust now I have uninstalled all old Microchip software (ver 1...something) from my PC (Win 10) using Windows Control Panel, I downloaded latest version of MPLAB-X, I plugged in PickIt-3 from 2 years ago without pressing any buttons on it and voila, it just worked. Whole procedure took about 12-15 minutes including time to update firmware on PickIt after I have selected the target device (PIC16). I guess it was fast because I expected that it would not work, so it is like Murphy in reverse?

author: Stonent
author_rank: Super Contributor
timestamp: January 19, 2016, 07:55:15 am
content: Just heard it a lot

author: AndyC_772
author_rank: Super Contributor
timestamp: January 19, 2016, 08:06:53 am
content: I feel compelled to ask what it is I'm doing 'wrong'.I use a PICKIT3 regularly, and it just works. For development, for production, in programmer-to-go mode which my customers love. It just works, every time, no problems at all. It works for me, and it works for the customers I have using boards with PICs in them.I know it's a major PITA when equipment doesn't "just work", and long-term readers will know I have no tolerance for quirky lab gear. If you've found issues with the PICKIT3, I totally sympathise. 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 notthatbad!

author: Howardlong
author_rank: Super Contributor
timestamp: January 19, 2016, 08:29:38 am
content: Quote from: AndyC_772 on January 19, 2016, 08:06:53 amSo 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.

author: jaromir
author_rank: Unknown
timestamp: January 19, 2016, 08:48:58 am
content: 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.

author: mux
author_rank: Regular Contributor
timestamp: January 19, 2016, 09:31:30 am
content: Quote from: Howardlong on January 19, 2016, 08:29:38 amOnce 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 2002And 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.

author: LazyJack
author_rank: Frequent Contributor
timestamp: January 19, 2016, 09:50:14 am
content: I just can't wait Microchip buying Atmel and use MPlab on AVR.

author: EEVblog
author_rank: Unknown
timestamp: January 19, 2016, 09:55:25 am
content: Quote from: LazyJack on January 19, 2016, 09:50:14 amThey did it a couple of years back:

author: EEVblog
author_rank: Unknown
timestamp: January 19, 2016, 10:01:09 am
content: Quote from: Dinsdale on January 19, 2016, 07:16:28 amCareful you don't brick your AVR chip by playing with those config bits!

author: Brumby
author_rank: Unknown
timestamp: January 19, 2016, 10:29:24 am
content: Quote from: AndyC_772 on January 19, 2016, 08:06:53 amYou must be young. This is the way of the world for most things - PICkits included.

author: Psi
author_rank: Super Contributor
timestamp: January 19, 2016, 12:17:20 pm
content: Need to rename the video "A typical day in the life of a PIC software engineer"

author: philn
author_rank: Newbie
timestamp: January 19, 2016, 01:56:34 pm
content: 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.

author: Supercharged
author_rank: Regular Contributor
timestamp: January 19, 2016, 05:19:47 pm
content: Quote from: philn on January 19, 2016, 01:56:34 pmHe said he is developing it with another company so maybe they don't want him to talk about it

author: ercapoccia
author_rank: Regular Contributor
timestamp: January 19, 2016, 06:23:23 pm
content: Just tried my PicKit3 i got from banggood with MPLAB IPE and it worked like a charm.

author: roli
author_rank: Regular Contributor
timestamp: January 19, 2016, 06:51:30 pm
content: 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.

author: Alexei.Polkhanov
author_rank: Frequent Contributor
timestamp: January 19, 2016, 06:54:18 pm
content: 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.

author: c4757p
author_rank: Super Contributor
timestamp: January 19, 2016, 07:23:18 pm
content: 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 thatdoesn'ttranslate to "Microchip developers are incompetent".

author: VinzC
author_rank: Frequent Contributor
timestamp: January 19, 2016, 07:25:51 pm
content: 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...

author: TheCharels
author_rank: Contributor
timestamp: January 19, 2016, 11:15:54 pm
content: 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.

author: artag
author_rank: Super Contributor
timestamp: January 19, 2016, 11:33:46 pm
content: Dave does like to rant .. but badly documented introductory tools deserve it. How would you have had him handle it ?

author: MT
author_rank: Super Contributor
timestamp: January 20, 2016, 12:44:12 am
content: Quote from: c4757p on January 18, 2016, 11:08:48 pmThat'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!

author: Brumby
author_rank: Unknown
timestamp: January 20, 2016, 01:18:14 am
content: Quote from: philn on January 19, 2016, 01:56:34 pmSome phrases for you:- Commercial-in-confidence- Industrial secret- Non-disclosure agreementThese 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 theabsoluteneed 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 onarenotrequiredfor 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:QuotePlease. 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!!

author: pciebiera
author_rank: Newbie
timestamp: January 20, 2016, 03:44:41 am
content: 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.

author: Monkeh
author_rank: Super Contributor
timestamp: January 20, 2016, 03:50:55 am
content: Quote from: pciebiera on January 20, 2016, 03:44:41 amAnd 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.

author: nixfu
author_rank: Unknown
timestamp: January 20, 2016, 04:36:44 am
content: 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.

author: FrankBuss
author_rank: Unknown
timestamp: January 20, 2016, 05:17:45 am
content: Quote from: nixfu on January 20, 2016, 04:36:44 amDepends 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.

author: EEVblog
author_rank: Unknown
timestamp: January 20, 2016, 05:59:22 am
content: Quote from: pciebiera on January 20, 2016, 03:44:41 amSomething that's not even mentioned in the PICkit3 user guide IIRC.And even then you have toknowyou 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.

author: EEVblog
author_rank: Unknown
timestamp: January 20, 2016, 06:02:08 am
content: Quote from: TheCharels on January 19, 2016, 11:15:54 pmRubbish, the tool should have worked. Or handled it better.QuoteIt's not like I hacked the tool in the past, I simply used it as it was intended to be used, withtheirtool. 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?

author: EEVblog
author_rank: Unknown
timestamp: January 20, 2016, 06:07:12 am
content: Quote from: philn on January 19, 2016, 01:56:34 pmBecause the company who is actually developing it is paying for that development. Agreements are in place. It is understandable they do not want me talking about every aspect of the development with the public.QuoteThat has never has been the case for my "Video Blog".There are some others that do that if that's what you are after.

author: EEVblog
author_rank: Unknown
timestamp: January 20, 2016, 06:13:32 am
content: Quote from: Brumby on January 20, 2016, 01:18:14 amYes, I'm usually open to a fault. If I say I can't show something then there are good reasons for that. Sometimes it might be a legal reason, sometimes it might just be personal preference (e.g. to avoid a flood of "why didn't you do this or that" bitching comments, or I simply don't think its worthwhile shooting and releasing something on it) or anything in between.As for the product in question, I would love to blog the development of it, but I legally can't do that.

author: mux
author_rank: Regular Contributor
timestamp: January 20, 2016, 09:04:04 am
content: Don't get too worked up about this, Daveit's absolutely impossible to satiate everyone.

author: philn
author_rank: Newbie
timestamp: January 20, 2016, 11:48:30 am
content: Quote from: EEVblog on January 20, 2016, 06:07:12 amOkay, I get that. I thought you were talking about the uCurrent or other EEVBlog products you are currently developing, because that's what I think would be great to see more of on the blog.

author: TheCharels
author_rank: Contributor
timestamp: January 20, 2016, 01:23:01 pm
content: Quote from: EEVblog on January 20, 2016, 06:02:08 amWhat appears in your video shows that latest versions of MPLAB (X and v8.92) are used to attempt to connect to the PICkit3. Then the oldest version of the PICkit3 standalone GUI, then the final PICkit3 standalone GUI. This is the one that seems to have gotten it sane enough to work with MPLAB.That you needed to use all these steps to get MPLAB to connect suggests that when you last used the PICkit3 you left it in a mode where only the standalone GUI could connect to it. Your fault? No. Contributory negligence maybe.I agree that this is an awful lot of fiddling around. Microchip tools must have better messages to inform casual users that the ICD tool needs updated firmware. Coughing up a "cannot connect" message is just BS.

author: Tek_TDS220
author_rank: Regular Contributor
timestamp: January 20, 2016, 04:18:11 pm
content: I've used both the AVR IDE and MPLAB X (with an ICD3). I much prefer the MPLAB X environment, and I mostly use Microchip parts as a consequence. I know this is a matter of taste. MPLAB X is incredibly powerful, the editor is wonderful, and it is free! Dave's complaints are mostly legitimate, but he goes way overboard in my opinion.Why is not downloading the compiler at the same time a problem? I think Dave is underestimating the problem of translating source code to new compiler versions.As for problems with downloading, I've never had a problem from my relatively slow connection.

author: D3f1ant
author_rank: Frequent Contributor
timestamp: January 20, 2016, 07:15:41 pm
content: I prefer the MplabX IDE too. If you disabled all the plugins you don't use/need/want it loads a bit faster. A feature of the pickit3 I really like is the program to go function, saves so much time when you have load firmware into a large batches of prototype devices. They say not use it for 'production programming' but from what I understand that is only because the pickit can't verify over a wide enough voltage range. I don't see that being a problem if your running the mcu on a regulated supply.ICD3 is better/faster/more capable tool, and you can pick them up for a discount during E14 sales, or during Microchips own sales.

author: mux
author_rank: Regular Contributor
timestamp: January 21, 2016, 10:48:31 am
content: Tek/Defiant: do you prefer MPLAB X to Atmel Studio (the Visual Studio fork) or to AVR Studio? Because I can understand the latter, but I can't see how anything trumps visual studio. It's a programmer's dream, maybe aside from Sublime. If you're already accustomed to C#/C++ programming in VS2012+, it's also very easy to get into.

author: forrestc
author_rank: Unknown
timestamp: January 22, 2016, 11:51:06 am
content: Quote from: mux on January 21, 2016, 10:48:31 amI can't compare with the AVR, but I will mention that MPLABX is Netbeans underneath. It even handles netbeans plugins which are for the underlying version of netbeans.For me, this is awesome since I do a lot of embedded web server work on the PIC's. As a result, I can actually do the web development for the web pages which live in the embedded system right on the box. It's also GCC and a pretty standard make under the surface for PIC32's, so you can do some of the customization you'd expect.-forrest

author: Simon
author_rank: Unknown
timestamp: January 22, 2016, 09:54:47 pm
content: God help atmel if they sell out to microchip, or rather god help those of us who will want to use the parts that actually do whjat we want. The equivalent AVR programmers do not do all this bollocks where to have to set it to differrent modes and download new firmware to the programmer every time you change device category. it's nuts.

author: TheCharels
author_rank: Contributor
timestamp: January 23, 2016, 07:39:06 am
content: After a 40 minute rant on using the PICkit3 with MPLABX how long will the rant on MPLABX be when Dave has used it to develop code?MPLAB v8.92 is old, feature poor but at least it has behaved consistently. MPLABX is moody. At times these advanced "features" of the editor fail to work as expected. I've been using v3.10 for a while now and know about most of the issues. I am wary of upgrading to v3.20 until more users have reported on its behavior.I just hope Dave have a boring productive experience so I can move on to MPLABX v3.20 confident that Microchip has done a good job.

author: bitwelder
author_rank: Super Contributor
timestamp: January 23, 2016, 09:20:29 am
content: Quote from: EEVblog on January 20, 2016, 06:13:32 amDo you think you will be (legally) able to walk through the product development, once the product will be out?(If so, please remember to collect some clips while you're developing on it)

author: vloki
author_rank: Newbie
timestamp: January 23, 2016, 11:50:31 am
content: Quote from: EEVblog on January 18, 2016, 10:00:28 pmJust another "good example" of what can happen if users don't read the readmeand forget all the hints they get when switching the PK3 OS.Anyway very entertaining

author: Howardlong
author_rank: Super Contributor
timestamp: January 23, 2016, 01:36:30 pm
content: Quote from: vloki on January 23, 2016, 11:50:31 amRiiiight. There speaks the voice of experience. Not! Not a week goes by without something not working on a hardware debugger. Debugging the debugger is regrettably an accepted tax on development time, indeed it's a rare but pleasant surprise when it does work as expected.

author: vloki
author_rank: Newbie
timestamp: January 23, 2016, 01:39:53 pm
content: Quote from: Simon on January 22, 2016, 09:54:47 pmGuess the devellopers of these products have been clever enough not to budge to the customerscomplains and did not give them what they want. It's more easy to service if there is only one mode...

author: Feynman
author_rank: Regular Contributor
timestamp: January 23, 2016, 02:12:29 pm
content: I rather use a good IDE with shit tools, than a shit IDE with shit tools. So I use MPLAB X

author: Drazn
author_rank: Newbie
timestamp: January 23, 2016, 03:35:53 pm
content: I'm with MC for some 15 years, MC Design House and ex Distributor. Only what I can say MC software is crap. X is enormous, slow Java crap. MC is NOT for professional use! Even today X has problems with breakpoints (all MC IDEs have this problem) and very slim functionality compared to ARM tools. Compilers, even they are GCC (x16 and x32), have problems (eg breakpoins again). Expensive RealICE could not be compared to cheaper and more powerful Segger.For last two years I'm on ARM and thats totally different story, software and hardware. Debuggers are more expensive than RealICE (Lauterbach 5000Eur, DSStream 3000Eur, Segger 500-900Eur) but what you get and what you could do is light years ahead of MC. Java crap Eclipse is faster than X with identical functionality.ARM (M3) is more powerful than PIC32 (MX series)- various features like FBP, DWT, etc. My JTAG speed is 25MHz! with 30cm cable and NEVER any problem during debugging. As different to RealICE where communications error are normal. Not to mention Performance Pack where for 150Eur you do not even get plastic box! Or 70 USD trace cable for PIC32 with 20 cm flat cable, few resistors, PCB and connector!Identical story for MC libraries, not to mention crap called Harmony.And now Atmel is going to become software disaster! I'm sure MC is not going to support Visual Studio for PICs!

author: VK3DRB
author_rank: Super Contributor
timestamp: January 24, 2016, 11:43:33 am
content: Microchip is nowhere near as bad as Microsoft. Installing the super-bloatware Visual Studio Community Edition produces strange errors come up on the PC. I spent 2 days frigging around with trying to install this rubbish and in the end gave up. Based upon the many bugs and bad UI in recent versions of MS Word, I can only conclude Microsoft is not funding their R & D properly, or are outsourcing the R & D to India. Maybe Gates and Bullmer hand back some of their loot for hiring decent project managers, programmers and test people. I work with a Visual Studio guru who agrees Microsoft has seriously gone downhill in the last few years. I noticed when the MPLAB crashed, Microsoft's error message inviting you to check for a solution on-line. Why didn't Dave click on that option? Because he, like everyone else, knows Microsoft will just waste their time with some answer aimed at old age pensioners.At least with the PICkit 3, once it is working it is pretty rock solid. It is a little slow though and the ICD 3 is much faster. And at least it is a genuine PICkit 3 and not an pirated device made by some comrade in China. Good luck with the project. The 24 series are pretty good chips.

author: mux
author_rank: Regular Contributor
timestamp: January 24, 2016, 06:53:00 pm
content: That must be some serious grudge against Microsoft, because basically the one and only reason they're so successful is because they've always been such a good platform for developers, developers, developers. Visual Studio is the bomb and VSCE is no exception. It's one of those tools, like IntelliJ IDEA, where the tool really does so much for you that you don't even consider it until you have to switch to something else and suddenly realize how much unnecessary typing and searching you have to do all of the sudden.Doesn't mean they're perfect, but they're far from buggy and bloatware. If that was your experience, you've probably done something wrong on your end?Also... Neither Gates nor Ballmer have anything to do with this and haven't had for over 10 years now

author: Len
author_rank: Frequent Contributor
timestamp: January 24, 2016, 09:33:55 pm
content: Quote from: VK3DRB on January 24, 2016, 11:43:33 amI use Visual Studio Community and Pro editions on several PCs and I haven't had any strange errors. (Except in my own code of course.)

author: VK3DRB
author_rank: Super Contributor
timestamp: January 24, 2016, 09:50:48 pm
content: Quote from: mux on January 24, 2016, 06:53:00 pmSounds like Dick Smith.Thinking about Dave's PICkit in the wrong mode, smart software would have told him it in the wrong mode - like a warning message when it could not connect. No fault by Dave at all. Good software design would have save Dave a day's work.

author: Drazn
author_rank: Newbie
timestamp: January 25, 2016, 07:14:42 pm
content: Quote from: VK3DRB on January 24, 2016, 11:43:33 amThere is a BIG difference between MC and MS, VS is complete Windows (x86, x64 and ARM) development suite with compilers, SDKs, various editors (eg graphics) and help system for all of above. In VS are included SEVERAL (one of the best) compilers - C/C++, C#, F#, etc. Not to mention resource "compiler", help, installation.X is ONLY IDE, buggy IDE and awfully slow! Did you tried to press F1 in source file with caret on some C function or PIC register? What about InteliSense? I can just ha ha haI agree with one: VS is getting worse! It started with VS.net, than disaster VS10. Latest VS2015 is big speed improvement to 2013.

author: FrankBuss
author_rank: Unknown
timestamp: February 09, 2016, 02:18:39 pm
content: Another interesting problem: Don't press the black button of the PICkit3 (program-to-go function), it can brick your PICandthe programmer:http://www.microchip.com/forums/m635420.aspxMight be releated to the comment later in the thread last year, that the PICkit3 can only provide 30 mA if you power your board from it, and behaves undefined if your board needs more. A bit more current would have been nice, or at least one more dollar worrth of parts for over current protection.

author: mux
author_rank: Regular Contributor
timestamp: February 11, 2016, 11:35:21 am
content: I like this concept of a 'DO NOT PRESS THIS'-button. Adds a bit of spice to an otherwise dull life.

author: cezar
author_rank: Contributor
timestamp: February 15, 2016, 03:05:13 pm
content: Did anyone notice that?https://www.microchip.com/mplab/mplab-xpress

author: Howardlong
author_rank: Super Contributor
timestamp: February 16, 2016, 10:27:06 am
content: Quote from: cezar on February 15, 2016, 03:05:13 pmNo but I have now. All was going well... until I tried to make it work with the ****ing debugger.

author: FrankBuss
author_rank: Unknown
timestamp: November 04, 2017, 11:27:27 pm
content: Posting it here, because someone here might know a solution, but looks like it is another annoying unfixed problem with PICKit 3: They removed the possibility to recalibrate the OSCCAL word for the older devices, if I didn't miss something:https://www.eevblog.com/forum/beginners/pic-12f509-the-target-has-invalid-calibration-data-(0x00)/Glad I still have my PICKit 2 as well.

author: forrestc
author_rank: Unknown
timestamp: November 05, 2017, 01:43:57 am
content: Quote from: FrankBuss on November 04, 2017, 11:27:27 pmAccording to the datasheet for these devices:QuoteAll you should need to do is ensure an appropriate MOVLW instruction is in the last word of program memory, preferably based on reading what was placed there from the factory. I haven't tested this to see if it works. But I also haven't used the internal oscillator in years (crystals are too inexpensive not to use, and I'm not space sensitive).

author: FrankBuss
author_rank: Unknown
timestamp: November 05, 2017, 02:48:42 am
content: Yes, but the value can get deleted, as the other thread I linked showed (and other people on the Microchip forum had the same problem), and it might be more accurate if it is possible to do the calibration again.

author: forrestc
author_rank: Unknown
timestamp: November 05, 2017, 05:08:44 am
content: Quote from: FrankBuss on November 05, 2017, 02:48:42 amAhh, I missed the 'auto regenerate' option....I'm surprised someone hasn't written a chunk of code to deal with this particular issue (i.e. output a squarewave on a pin, then adjust per measurement).

author: FrankBuss
author_rank: Unknown
timestamp: November 15, 2017, 06:08:19 am
content: Finally I got a response from Microchip support: "I got a response from our development team. As of the moment, there is no plan in supporting OSCCAL feature in PICkit 3.". So now it is official: PICkit 3 is worse than PICkit 2.

author: bloguetronica
author_rank: Frequent Contributor
timestamp: November 15, 2017, 11:33:38 am
content: Talking about nightmares. PICkit 3 is an absolute nightmare and sometimes it just doesn't work. Both the software and hardware are too complicated and prone to fail. I almost bricked the thing once. I ceased to use PICs a long time ago, because the programming tool is garbage and you need to pay just to optimize the code.Now I use the Parallax Propeller with an FTDI UART (but any kind of USB to UART converter will do). The software tool SimpleIDE works on Linux as well as on Windows. It works every time, provided I don't mess up the definitions. It supports all configurations you can think of, clock rates, baud rates, you name it. Never had any problems with it. Bricking it is pretty much impossible.