What Microchip hides from Dave after his Pickit3 video, yes new Pickit4 :)

[ucanel]

http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=PG164140
  I saw Microchip new Pickit4 announcement,
first thing come to my mind is Dave's Pickit3 video.
I wonder will Dave give us a chance to see him struggling with the
new Pickit4, maybe along with uCalc uWatch or uSupply.
There is a chance that microchip already send a Mailbag
just hiding around somewhere in Dave's Lab who knows.

I'm just kidding,
I would like to see a video for Pickit4 from Dave.

RaMu | ucanel

[thm_w]

I like the SD card idea, I'm sure that could be useful with the right software. Also sure that Mike will get his hands on one and do a good review.

The MPLAB PICkit 4 In-Circuit Debugger/Programmer supports many, but not all, PIC MCUs and dsPIC DSCs at this time. The firmware is continually being upgraded to add support for new devices. To request priority device support or to report issues, email: PICkit4_Update@microchip.com

"PIC MCU" apparently includes AVR and SAM ARM mcu's which is really confusing. But it sounds like we might be lucky and get a lower cost atmel SWD programmer (for commercial use, jlink is cheaper for edu):

Along with a wider target voltage, the MPLAB PICkit 4 supports advanced interfaces such as 4-wire JTAG and Serial Wire Debug

http://ww1.microchip.com/downloads/en/DeviceDoc/00002618A.pdf

[stj]

it even comes with stickers!! /sarc

but seriously, no schematic yet - so not an open design?

[NiHaoMike]

Didn't he do a joke video of the "prototype" PICkit 4 some years back saying that PIC and AVR would be unified? How surprising to see it start to come true!

Also sure that Mike will get his hands on one and do a good review

I'll gladly take one if they're giving some away, but otherwise I'll stick with my PICkit 3 until I really need to use a part it doesn't support. (For the record, the PICkit 3 is pretty good although I don't like how the programmer itself has to be reflashed for different chip families. Really annoying when working on a design that has multiple PICs of different families!)

[KL27x]

I hope they manage to keep the bloat and bugs out of this version. 

but seriously, no schematic yet - so not an open design?

If it's as complicated as the PK3, I don't really care. It's not like you'd make one, yourself. Cheap clones are fine and all, but for $57.00 (and a removeable SD card), I can live with that.

[hans]

Quite interested to see the teardown of this thing. I wonder what MCU/chipsets they used now that the Microchip design team has access to all the fancy Atmel ARM and AVR parts..

Also I hope they have fitted a part that is large enough to support all programming paradigms at once. The frequent reflashing of PICKIT3 between series was agonizing with it's slow- and buginess.


But yes, funny that the April fools joke of Dave many moons ago finally became true.

[JPortici]

Quite interested to see the teardown of this thing.

me too!

of course there's no support (yet) for almost all the parts that i use (dsPICs with codeguard) but the feature list is interesting (they added JTAG!)

[mikeselectricstuff]

Just ordered one...

[jpanhalt]

Notably absent from the announcement is whether it will be compatible with MPLAB 8.92.   I suspect it will not be.

[mikeselectricstuff]

I can't imagine for a second that it would be compatible with MPLAB 8.x

[tszaboo]

Didn't he do a joke video of the "prototype" PICkit 4 some years back saying that PIC and AVR would be unified? How surprising to see it start to come true!

Also sure that Mike will get his hands on one and do a good review

I'll gladly take one if they're giving some away, but otherwise I'll stick with my PICkit 3 until I really need to use a part it doesn't support. (For the record, the PICkit 3 is pretty good although I don't like how the programmer itself has to be reflashed for different chip families. Really annoying when working on a design that has multiple PICs of different families!)

Actually, I think they should release something that would support all AVR/ARM/PIC micro in their lineup. After all this is mostly software.

[JPortici]

http://www.globenewswire.com/news-release/2018/02/27/1395611/0/en/Low-Cost-Debugging-and-Programming-is-Now-Faster-and-More-Feature-Rich-with-MPLAB-PICkit-4-Development-Tool.html

This low-cost programming and debugging solution is ideal for those designing in the 8-bit space, but it is also perfectly suited for 16- and 32-bit development due, in part, to its 300 MHz, high-performance ATSAME70Q21B microcontroller on board

[Maxlor]

If you're ordering from microchipdirect.com, the code EW2018DT should give you 25% off.

[JanJansen]

Also I hope they have fitted a part that is large enough to support all programming paradigms at once. The frequent reflashing of PICKIT3 between series was agonizing with it's slow- and buginess.

You mean when programming another chip then it starts : downloading AP...
When i install the MPLABX from version 3 and up it will hang right there,
if they fix it i might be able to install the latest MPLAB.

[KL27x]

^ I believe I encountered that problem, at first.

I think w/e firmware is initially loaded on the programmer can be incompatible with the version of IPE/X you are using, for instance. So when it starts the family/device download, it fails to work.

If this is the same problem I had, you can fix it by selecting "manual firmware update" and finding the firmware suite file which comes with your version of X/IPE, which IIRC is in a folder called PK3. It is maybe in a compressed .JAR file. The name is something along this line, with 6 digit number as follows:

0x.xx.xx.jar   

(it might have a prefix like "fw_", but the memory is hazy) Incidentally, this 6 digit number will pop up in the dialog window when you first connect your programmer as "firmware suite 0x.xx.xx," or something along those line. And I bet anything the number that pops up is lower than what is included in your version of X/IPE. I think early adopters probably didn't run into this problem. I waited a couple years before trying out X and PK3... and if you get an old stock PK3 and downloaded say a specific version of X, I think this is where you get this issue. Maybe the latest version of software fixes this hole in the update bridge. But I had to do this with my genuine and my clones.

You do not need the whole image or another programmer to burn it. It's just a matter of clicking on the right things. The only way to figure this out, though, is to skim the forum thread and find your particular problem(s). I never found any official documentation that would have helped me.

[mikeselectricstuff]

Just received one - no time to play at the moment, just some pics.
Front button is stupid - you squeeze the case to operate it, which makes it harder to use handheld in "to-go" mode with a spring-probe on the end
Similar wanky light-guide to ICD4
USB Micro

8 pin connector ( vs. 6) so presumably support for Atmel and maybe JTAG. Not checked yet but If the first 5 don't match the old pinout i will not be happy.

And still no bloody pinouts printed on the case.

[hans]

Well, it should support 5 and 6-pin ICSP interfaces:

Supports advanced interfaces such as 4-wire JTAG and Serial Wire Debug with streaming Data Gateway

Backward compatible for demo boards, headers and target systems using 2-wire JTAG and ICSP

Also, the product is still in progress:

An additional micro SD card slot and the ability to be self-powered from the target means you can take your code with you and program on the go.*
[..]
* This functionality is coming soon with firmware update of the product through MPLAB X IDE.

The MPLAB PICkit 4 In-Circuit Debugger/Programmer supports many, but not all, PIC MCUs and dsPIC DSCs at this time. The firmware is continually being upgraded to add support for new devices. To request priority device support or to report issues, email: PICkit4_Update@microchip.com

Curiously there is also no real datasheet on the product page yet, which should describe e.g. pinouts for JTAG mode and/or the extended 2 pins.


Also apparently they are bragging about the use of the Atmel Cortex m7 300MHz CPU in this programmer (and USB2.0 High-Speed), making it much faster.
Sounds like a claim to be tested, perhaps even compare it with the PICKIT 2 which was often faster [for me in MPLAB X] to use than PICKIT 3.

[igendel]

Not checked yet but If the first 5 don't match the old pinout i will not be happy.

The latest video from Microchip about the PICKIT4 said the first 6 pins match the old pinout.
I'm still waiting for someone to figure out if this needs constant firmware uploading when switching between devices. If not, I'll be buying it immediately

[Maxlor]

8 pin connector ( vs. 6) so presumably support for Atmel and maybe JTAG.

The Microchip representative at Embedded World told me that JTAG is exactly what those are for, and that it'll work in a few months. I wonder... is it too much to hope for that OpenOCD will support the PICKit4 eventually, turning it into a universal programmer? 

[hans]

I think that completely depends on the complexity of setup and protocol attached to the PICKIT4. I'm sure it will be figured out at some point; however if programming executives are needed to switch target families then I'm not so sure.

However, ofcourse there could also be a firmware-level protection in the device. E.g. when setting up a JTAG connection, the device initiates a read device ID itself, and if it does not match the MicroChip/Atmel vendor ID will abort all further JTAG commands...

[mikeselectricstuff]

It does not appear to download new FW when changing device family.
An issue I've found is that it appears to keep  the PGC/PGD pins set as outputs when idle which casues bus clash and power draw

I've not yet found any info on the SD card functionality.

No more time to play

[BrianHG]

Just received one - no time to play at the moment, just some pics.
Front button is stupid - you squeeze the case to operate it, which makes it harder to use handheld in "to-go" mode with a spring-probe on the end
Similar wanky light-guide to ICD4
USB Micro

8 pin connector ( vs. 6) so presumably support for Atmel and maybe JTAG. Not checked yet but If the first 5 don't match the old pinout i will not be happy.

And still no bloody pinouts printed on the case.

Are they seriously expecting that button and squeezing that case to last thousands of cycles.

[tszaboo]

The Pickit 4 has a Atmel SAM microcontroller in it.
Oh the irony...

[KL27x]

An issue I've found is that it appears to keep  the PGC/PGD pins set as outputs when idle which casues bus clash and power draw

I wasn't aware that the PK3 DIDN'T do this. The PK2 has low impedance to ground on the PGC/D pins when idle, too. If you're keen enough to fix this problem, you can. I did it on my ole PK2 used for dev work using 2 SSR and a micro that triggers them when Vpp is detected and holds them closed for X amount of time after Vpp is no longer detected. (There's a couple transistors on the PK3 schematic that short the PGC/D to ground, and I thought I could get creative and just interrupt those at their gates/bases, but this didn't work, and I had to use 2x SSR).

Front button is stupid - you squeeze the case to operate it, which makes it harder to use handheld in "to-go" mode with a spring-probe on the end

This is an even easier fix. Esp since this device has a new 8 pin header on it, already, and even potentially has a different pinout (which I highly doubt they'd do that... but...)

What I do to my PK2 and 3's is to open the case and remove the female 6 pin header. Not the pins, just the plastic part. File out the case on one side to fit a 7 pin header. Then take a 7 pin header, remove 6 of the pins, and slide it on. Jumper wire the new pin7 to the button trace. Then put a button right on your spring probe.

Heck, my PK2 have had removeable EEPROM for a decade, before this SD card thing came out.

I'm surprised you got your PK4 already. When I order it, it says it will ship mid March.

[mikeselectricstuff]

An issue I've found is that it appears to keep  the PGC/PGD pins set as outputs when idle which casues bus clash and power draw

I wasn't aware that the PK3 DIDN'T do this. The PK2 has low impedance to ground on the PGC/D pins when idle, too. If you're keen enough to fix this problem, you can. I did it on my ole PK2 used for dev work using 2 SSR and a micro that triggers them when Vpp is detected and holds them open for X amount of time after Vpp is no longer detected. (There's a couple transistors on the pcb that short to ground, and I though I could get creative and just interrupt those, but this wasn't enough, and I had to use 2x SSR).

I frequently use an ISP pin to transmit UART debug output ( using in programmer mode, not debugger, obviously) - no reason the programmer should be driving the pins when not active. 
There might be a setting somewhere to control this

I'm surprised you got your PK4 already. When I order it, it says it will ship mid March.

Plenty showing in stock at Microchip direct

[KL27x]

Maybe because I am in the US. Microchip direct ships to me from their Thailand location. Maybe in the UK, you are covered by a different distribution center.

I frequently use an ISP pin to transmit UART debug output ( using in programmer mode, not debugger, obviously) - no reason the programmer should be driving the pins when not active. 
There might be a setting somewhere to control this

At any rate, even if there's not, this hardware fix will probably work fine, if/when you have the time. You just have to find a signal to trigger it off of. So the relays can close and connect the PK to the PGC/D pins when it needs them, and cut it out of circuit the rest of the time. For me, the only downside of closing those relays off the Vpp was that on the now obsolete baseline devices, the rewriting of corrupt OSCCAL didn't work. I just added two solder jumper pads to the outside of the case to permanently close the relays (and restore the programmer to stock configuration) if/when desired with a soldering iron. Not that the automatic recalibration was accurate enough to even bother with. But I did occasionally sit down a recalibrated a batch of chips with a calibration firmware and a frequency reading on a DMM. If you use the debugger, frequently, I suppose you need a different signal or to add an additional physical switch.

I got even fancier on the button thing, with my dev programmer. I made an intermediary pcb with in/out headers on it (straight pass through on the regular ICSP pins, and circuitry only on the new 7th button pin) with a USB mouse chip and a switch. So with the flip of a switch, the button on my ICSP pogo pin interface could act as left mouse button. This is so handy when you are debugging a product and you want to double check the firmware revision (assuming you can leave DATA EEPROM unlocked and give yourself a register or two for an firmware revision number). Hover the mouse pointer over the "read" icon in the software, and then you can read the device with your pogo interface without needing 3 hands or learning to use the mouse lefty. Universal, works with all programming software. If ever you needed to read/verify/erase or write with a pogo interface.

If it sounds like I spent a lot of time modifying PK's, yeah. My dev PK2 is permanently installed in my bench. It's that reliable. I think I only ever had to unplug/replug the USB plug once. My P2G PK's all have integrated Li ion battery, charger, 5V boost output, button mod with extra header pin. I'm not sure when I will have time to play with the PK4, but it will be upgraded, eventually.

[Howardlong]

[I originally posted this on the Microchip forum without the pics]

One of these arrived this morning. Very early days, but here are my initial findings.

The biggest problem so far is that I am having some trouble with it enumerating, I've tried different USB ports and hubs but it seems random, on the same port sometimes it enumerates, sometimes it doesn't. The error is

The last USB device you connected to this computer malfunctioned and Windows does not recognise it.

Recommendation

Try reconnecting the device. If Windows still does not recognise it, your device may not be working properly.

OS is Windows 10 x64 on a dual Xeon E5-2696v2 24C48T monster with 64GB RAM, so plenty of horsepower.

When it works, there is a dramatic improvement when programming over the PICkit 3, on a blinky on a PIC32MX170F256B, the PICkit 3 takes 22s whereas the PICkit 4 takes 7s. ICD 3 took 11s, so the PICkit 4 seems faster in this example than an ICD 3.

When programming (as opposed to debugging), unlike other programmers, the PICkit 4 seems to assert reset or otherwise stops the processor from running after programming. You need to remove the programmer from the DUT to see it run.

Unlike the PICkit 3, you can set breakpoints while the processor is running, which I use a lot on the ICD 3 and RealICE.

MPLAB X frequently seems to deny the PICkit 4 is connected after it's already enumerated correctly and been used. I'm not yet sure of the sequence of events that makes this happen, but restarting MPLAB X sometimes fixes it. Sometimes you have to change USB ports for it to show up in MPLAB X.

A welcome new feature of the PICkit 4 seems to be that it stores debugger firmware for several devices so it doesn't need to update every time you change devices. I don't know how many devices it will remember. I was swapping between a PIC24F08KA101 and PIC32MX170F256B.

In short it's promising, but as is so often the case nowadays with Microchip, the quality of the software and associated in house testing leaves an awful lot to be desired, leaving the rest of us to do that for them.

[mikeselectricstuff]

A welcome new feature of the PICkit 4 seems to be that it stores debugger firmware for several devices so it doesn't need to update every time you change devices. I don't know how many devices it will remember. I was swapping between a PIC24F08KA101 and PIC32MX170F256B.

I'd sincerely hope it now has just one FW image that covers all devices, and only needs updating when something new comes along or bugfixes.

I only had a quick look but haven't yet seen anything about the SD card functionality - will be interesting to compare the standalone programming speed, as this is something I use PK3 for a lot. I worry that the overhead for the SD protocol might actually make it slower, especially for smaller parts.
The fact that the product page links to the SQTP spec suggests it may now support serialisation in standalone mode, which would be nice.

[Howardlong]

It may well be the case that there’s no target-specific firmware at all stored on the programmer, or at least all the necessary algorithms are stored on the programmer ahead of time in a single image. I don’t remember seeing it going through the AP and RS etc programming stages that you get on the ICD 3 and PICkit 3.

I didn’t try any programmer to go functionality, it’s not something I use, so I didn’t feel I’d be able to do it justice, having no experience of using the finctionality in anger.

If the standalone programming speed is as fast as I’m seeing when PC attached, then I may well start to use that functionality. At present, any bulk production programming I have to is in an emergency, and is through the old IDE which is much faster than MPLAB X.

[josip]

When it works, there is a dramatic improvement when programming over the PICkit 3, on a blinky on a PIC32MX170F256B, the PICkit 3 takes 22s whereas the PICkit 4 takes 7s. ICD 3 took 11s, so the PICkit 4 seems faster in this example than an ICD 3.

And what is the size of that blinky example? To put programming rate in KByte/sec.

[JPortici]

If the standalone programming speed is as fast as I’m seeing when PC attached, then I may well start to use that functionality. At present, any bulk production programming I have to is in an emergency, and is through the old IDE which is much faster than MPLAB X.

programming-to-go IS blazing fast on pickit 3.
I use it when i have many boards that don't have a header, but it has contact pads instead: i press the button, programming done in a couple of seconds at most.
 
I'm sure that most of the lag come from the communication between programmer and software, because there is none when the PK3 is in PtG: blue led steady when last programming was successful, blinking if not successful. green and red led change states when the target is detected. If they'll add SQTP in PtG mode the PicKit4 it will make me very happy

[josip]

programming-to-go IS blazing fast on pickit 3.
I use it when i have many boards that don't have a header, but it has contact pads instead: i press the button, programming done in a couple of seconds at most.
 
I'm sure that most of the lag come from the communication between programmer and software, because there is none when the PK3 is in PtG: blue led steady when last programming was successful, blinking if not successful. green and red led change states when the target is detected. If they'll add SQTP in PtG mode the PicKit4 it will make me very happy

Because they don't know how to do it right. I am the author of flasher (not for PIC) that has no any latency related to PC (USB) -> target device data transfer, and it is faster than other (similar) tools that are replicating downloaded code (firmware stored in master device RAM, no PC connection).

Again, what is blazing fast programming rate (in KByte/sec)?

[hans]

I would be interested what the programming time would be if you leave the connection to the tool open. I also agree that connection setup overhead in Microchip devices is excessive.

In cases of my ARM toolchain flow, I've an openocd server constantly running that already has probed the target board for power, chip ID and memory setup. It can go straight to downloading code and running the executable whenever I do so. I think MPLABX has a similar option in their embedded section, that allows you to leave tool connection active outside programming/debug sessions.

Thereby I would suspect that if you want to measure kB/s for a small blinky program, you will probably get very low numbers. Better get some kind of large binary (e.g. 64 or 128kB) and time how long it takes extra.

[JPortici]

programming-to-go IS blazing fast on pickit 3.
I use it when i have many boards that don't have a header, but it has contact pads instead: i press the button, programming done in a couple of seconds at most.
 
I'm sure that most of the lag come from the communication between programmer and software, because there is none when the PK3 is in PtG: blue led steady when last programming was successful, blinking if not successful. green and red led change states when the target is detected. If they'll add SQTP in PtG mode the PicKit4 it will make me very happy

Because they don't know how to do it right. I am the author of flasher (not for PIC) that has no any latency related to PC (USB) -> target device data transfer, and it is faster than other (similar) tools that are replicating downloaded code (firmware stored in master device RAM, no PC connection).

Again, what is blazing fast programming rate (in KByte/sec)?

I haven't measured it tbh but it goes from 5-10 seconds to just after the button is pressed. Fast enough for me, i use programmer-to-go in PIC16LF1823 based boards, just a couple of kilobytes to transfer

[josip]

I would be interested what the programming time would be if you leave the connection to the tool open.

If this question is related to me (and my flasher), than there will not be any difference, because there is no latency (of any kind) during sending data over USB (CDC, unlimited size buffer, complete firmware is sent at once). Programming time will be identical.

Thereby I would suspect that if you want to measure kB/s for a small blinky program, you will probably get very low numbers. Better get some kind of large binary (e.g. 64 or 128kB) and time how long it takes extra.

I hope that this blinky using full flash memory, because I can't imagine that today (2018) some brand new tool need 7 seconds for downloading 1 KByte program. And that is reported as miracle.

[josip]

I haven't measured it tbh but it goes from 5-10 seconds to just after the button is pressed. Fast enough for me, i use programmer-to-go in PIC16LF1823 based boards, just a couple of kilobytes to transfer

This is too slow for me, but I am not familiar with PIC and it's flash memory characteristics.

For example, 20 years old MSP430F2xx devices are with flash memory that is limited to 50 KByte/sec writing rate.

[ggchab]

If you're ordering from microchipdirect.com, the code EW2018DT should give you 25% off.

Thank you. I just ordered a pickit4 and the code worked perfectly 

I contacted Microchip to know when a specific dsPIC33 will be supported and they replied "Support for these parts should be in the April release of MPLAB X v4.20". This might also fix the connection problem ...

[mikeselectricstuff]

programming-to-go IS blazing fast on pickit 3.
I use it when i have many boards that don't have a header, but it has contact pads instead: i press the button, programming done in a couple of seconds at most.
 

It is somewhat dependent on the part and the code size - I've seen from 2 to about 20 secs

[Howardlong]

If you're ordering from microchipdirect.com, the code EW2018DT should give you 25% off.

Thank you. I just ordered a pickit4 and the code worked perfectly 

I contacted Microchip to know when a specific dsPIC33 will be supported and they replied "Support for these parts should be in the April release of MPLAB X v4.20". This might also fix the connection problem ...

I noticed most, if not all, of the dsPIC33Ex and PIC24Ex series aren't yet supported in the MPLAB X 4.15 release notes. In addition among others, some of the early PIC32MX aren't yet supported.

On Wondows installs, the default file location to check is: C:\Program Files (x86)\Microchip\MPLABX\v4.15\docs\Device Support.htm

[KL27x]

This is too slow for me, but I am not familiar with PIC and it's flash memory characteristics.

For example, 20 years old MSP430F2xx devices are with flash memory that is limited to 50 KByte/sec writing rate.

I wonder why such a huge difference? Maybe due to PIC internal charge pump circuitry? If I understand correctly, many of the modern micros are flashing themselves, in a way, rather than relying on the external programmer to get the voltage correct and potentially suffering voltage drop issues.

The flash speed certainly depends on the parts. In the 8 bit pics I use, the PK3 flashes almost exactly the same speed as PK2 in almost all cases and is essentially the same speed whether through USB or P2G. Roughly 3 to 3.5 seconds per KB. ICD3 is maybe 20-30% faster but much less convenient for batch flashing.

 

[NorthGuy]

Roughly 3 to 3.5 seconds per KB. ICD3 is maybe 20-30% faster but much less convenient for batch flashing.

There are lots of different PIC16/18, older are slower, newer ones are generally faster, but 3 sec/KB is certainly way too slow and the reason for this it is certainly bad PICkit3 design.

[cv007]

I see about 3K/sec for a pic32mm curiosity board (PKOB=PK3). When using the command line tools to program, it takes about 10 seconds for the programming software to get to the point of actually programming the chip.

I would rather see them take the cheapest pic32 w/hs usb, <5x5cm size, simple design, cut the parts count down, open source the hardware/software and let the best ideas float to the top. Sell them like candy, toss them out at parades, put them in vending machines. They could bundle this pk-mini with all future curiosity boards also (I don't see them slapping a $15 retail sam micro on future curiosity boards). 

question- since the PK4 will have JTAG(?), will this enable the use of JTAG debugging on something like the pic32mm which has that capability? I read about the J-link Base which can debug a pic32 (not mm) without using a debug executive. Or is this just their dream- add a few pins for the capability, but the software guys will need another 5 years to get to it (after they get the basic features to work right).

[KL27x]

Yeah, my mistake. Misremembered. Looking at the code I was using, I have almost 4x the size I thought I did. I'm seeing a little over 1KB per second on an enhanced midrange.

I don't remember having major difference with the basic 8 bit, though. Except with the PK2, it wants to write the entire program memory with 0's, because osccal is in the last register. PK3 was programmed to not be retarded on these PICs. Not that anyone uses these, anymore.

[josip]

I wonder why such a huge difference? Maybe due to PIC internal charge pump circuitry? If I understand correctly, many of the modern micros are flashing themselves, in a way, rather than relying on the external programmer to get the voltage correct and potentially suffering voltage drop issues.

Many micros can be flashed by themselves, and (most of the) PIC's too. And external programmers use the same principle. They download small part of flashing code to target device, and than execute it from there. Taking care to supply that executing program on target device with flashing data on time. And if this program on target device always have data on time (not waiting for them, and USB with 1 MByte/sec from PC side can provide this) then there should not be any (or some with minimum impact) latency.

I found this...
http://www.microchip.com/forums/m881530.aspx

Reason is very simple : Pickit2 uses internally a PIC18. Pickit3 uses internally a PIC24.
Both these PICs uses USB Full Speed (12Mbits/s)
ICD3 and Real-Ice have an internal FPGA which has USB High Speed (480Mbits/s)
 
If you use ICD3 or Real-Ice, you can program PICs up to 512KB in less than 15s ;=)
If you program a 512KB PIC32 with Pickit3, it will last about 3mn30.

Where is clear that they (Microchip) don't know how to do it. And they need a huge amount of horse power to compensate this. Or flash module on their devices is designed on bad way, and only huge amount of horse power can handle this. Again, their falut.

BTW, don't know how to comment this (from MPLAB ICD 3 features) at all...

High Speed Programming - Fast programming allows both quick firmware reload for fast debugging and for in-circuit re-programming. Programming times are improved up to 15x over MPLAB ICD 2.

That older version of the same product was so bad, that the new one is 15x faster, and they are proud because of this. 

Just want to add something to linked topic related to PIC flash writing speed and USB...
There is nothing wrong with USB, and CDC. USB is made for large transfer (at once) and in micro world (Full speed) up to 1 MByte/sec working just fine. It is not made for frequent transfer of small data chunks (few bytes). I can find on plenty of places where (slower) HID is preferred over "problematic" CDC. Maybe it is only me, but I didn't found any problems ever with CDC, that have native OS support, and today it is also on Win 10 plug and play (without driver installation request).

[stj]

i was going to get one, but after looking at the site i changed my mind.

marketing bastards have decided it wont work with AVR parts even though it's now a microchip range and the programmer could handle it.
they still want you to buy a seperate programmer!

hell, even pickit2 could do AVR unofficially - and pickit3 probably could with a little work.

[NorthGuy]

Yeah, my mistake. Misremembered. Looking at the code I was using, I have almost 4x the size I thought I did. I'm seeing a little over 1KB per second on an enhanced midrange.

I don't remember having major difference with the basic 8 bit, though. Except with the PK2, it wants to write the entire program memory with 0's, because osccal is in the last register. PK3 was programmed to not be retarded on these PICs. Not that anyone uses these, anymore.

Sure. Like the old PIC18F6723 can be fully programmed in 4.5 seconds while a newer PIC18F67K22 can be programmed in 3.3 seconds. They're both 128K memory (which BTW means that full speed USB has way more than enough bandwidth). Even with PICkit3, it is not as slow as you described. I timed these with PIC3CMD and it was 50 and 34 sec respectively - close to 3KB/s.

[Howardlong]

Yesterday I found that like the ICD4, the PICkit 4 won't anywhere near reliably debug devices like the PIC32MZ series when running at higher clock speeds. It consistently breaks after only three or four single steps.

This and a few other anomalies suggest that they've leveraged the ICD4 ancestry and ported it to this new device, which is a reasonable thing to do. Or it would be, if only it worked in the first place!

[cv007]

Where is clear that they (Microchip) don't know how to do it. And they need a huge amount of horse power to compensate this.

An example-
a 256k pic32mm has a chip erase time of 20ms,  a row write time of ~1.5ms which means 1024rows * 1.5ms + 20ms = ~1.5s to program the whole chip (these are self program numbers)
usb hid fs can do 64bytes x 1000 for irq transfers = 64000bytes/s (although I think one can use control transfers/reports to crank that up significantly)

so, the chip can do 256k in 1.5s, usb fs hid can transfer 256k in ~4sec, but it takes about ~80 seconds to program the 256k from the pickit3/pkob- I know there are a number of little gears between the input and output of this transmission system, but it does seem like the clutch (software) has some major slippage.

They could probably double the speed (or more) with not much effort, it would seem to me.

[NorthGuy]

Where is clear that they (Microchip) don't know how to do it. And they need a huge amount of horse power to compensate this.

An example-
a 256k pic32mm has a chip erase time of 20ms,  a row write time of ~1.5ms which means 1024rows * 1.5ms + 20ms = ~1.5s to program the whole chip (these are self program numbers)
usb hid fs can do 64bytes x 1000 for irq transfers = 64000bytes/s (although I think one can use control transfers/reports to crank that up significantly)

so, the chip can do 256k in 1.5s, usb fs hid can transfer 256k in ~4sec, but it takes about ~80 seconds to program the 256k from the pickit3/pkob- I know there are a number of little gears between the input and output of this transmission system, but it does seem like the clutch (software) has some major slippage.

They could probably double the speed (or more) with not much effort, it would seem to me.

Double? You can do much better. 1.5 sec is too optimistic, you need to transfer data to the chip, then spend some time on verification. But about 5-6 sec sounds about right. And you don't need FPGAs, fancy 32-bit MCUs to achieve this speed. You can get pretty good speed with a little programmer made of little PIC16.

[cv007]

Double? You can do much better

I was referring to MCHP, so I set the bar low with 'double' (and I also said without much effort).

1.5 sec is too optimistic

I was giving the minimum times for each potential bottleneck to show its not the chip or lack of HS usb. I always assumed moving to HS usb would make a big difference, but it appears that is not the problem. The speed gains of the PK4 are probably due to the fact that it can't get any slower than the PK3, and ANY rewrite of code would bring more speed.

[Howardlong]

Don’t forget they’ll be earing through 58 layers of abstraction, including JNI, to target the hardware.

You can see where the delays are to some degree when you hit the program or debug buttons.

If you compare it with the performance of the old MPLAB non-X, you wonder what “progress” is in the minds of some engineers.

[NorthGuy]

If you compare it with the performance of the old MPLAB non-X, you wonder what “progress” is in the minds of some engineers.

I wonder wouldn't it be easier for them to port pre-X MPLAB to Linux/Mac (if that's was the goal)? But I think they honestly believe MPLAB X is faster and better. Parallel reality.

With all these acquisitions, I now wonder if they're inclined to continue with PICs at all. I think they like AVRs better, so MPLAB is moving to AVR world and PICs are slowly retiring while donating their peripheral organs to new AVRs. Looks like a very possible scenario.

[josip]

An example-
a 256k pic32mm has a chip erase time of 20ms,  a row write time of ~1.5ms which means 1024rows * 1.5ms + 20ms = ~1.5s to program the whole chip (these are self program numbers)
usb hid fs can do 64bytes x 1000 for irq transfers = 64000bytes/s (although I think one can use control transfers/reports to crank that up significantly)

so, the chip can do 256k in 1.5s, usb fs hid can transfer 256k in ~4sec, but it takes about ~80 seconds to program the 256k from the pickit3/pkob- I know there are a number of little gears between the input and output of this transmission system, but it does seem like the clutch (software) has some major slippage.

They could probably double the speed (or more) with not much effort, it would seem to me.

Similar example:

MSP430G2955 is new device, but it belongs to 20 years old 2xx flash family. It has the same flash module as 20 years old 2xx devices, and I am using it for example only because of largest memory in 2xx family (and due to largest memory it will give best performance numbers for my flasher).

You can calculate maximum flash writing rate using datasheet numbers for block write (at 476kHz, that is max flash frequency), and it is (if I remember right) little over 50 KByte/sec (these are self program numbers). My flasher using little lower flash frequency of 461.5 kHz for target device flash, and by datasheet calculation for 128 bytes in flash clock cycles is...

25 (1st word, block start) + 63 * 18 (63 words) + 6 (block termination) =  1165

and with 461.5 kHz flash frequency, flash writing rate will be 49.5 KByte/sec (these are self program numbers).

Benchmark (write command) for my flasher with this target device connected, on Win / Linux / OS X, will show 48.3 KByte/sec. In this rate (time) is included elapsed time from the moment before PC send write command (with all data) to flasher and after PC receive information from flasher that job is done. For communication between PC and flasher is used CDC (OS drivers) that doesn't need any extra installation, plug and play.

Double? You can do much better. 1.5 sec is too optimistic, you need to transfer data to the chip, then spend some time on verification. But about 5-6 sec sounds about right. And you don't need FPGAs, fancy 32-bit MCUs to achieve this speed. You can get pretty good speed with a little programmer made of little PIC16.

And my flasher is based on 10 years old 24 MHz MSP430 device. Most important thing is to have all things running in parallel without any latency, but this must be hard coded in assembler, and there is nobody crazy enough (except me) today, to lose time on this. C++ with 5 abstraction layers is mostly used today (as I can see in TI FET's open sources), and in combination with people that don't know how to do it, result is as it is.

[Howardlong]

I've been attempting to use this device on a PIC16F1509 over the past couple of days.

First off, the PICkit 4 (and ICD 4) doesn't recognise the device's debug header, so I have had to switch around some pins on the DUT board to free up the debug pins.

Second, and it's early days, I found a "Hardware tool emergency boot firmware recovery" option in the Debug menu of MPLAB X 4.15. Nothing ventured, nothing gained. After a bit of fannying around, I reset the firmware on both the ICD 4 and PICkit 4, and, touch wood, since then the devices have behaved themselves, and enumerated. (I tried the PICkit 4 on two other PCs and experienced the same enumeration problems I'd been having on my main PC over a number of different USB ports and hubs). When in its recovery mode, it shows up as a COM port by the way.

If you unplug and immediately plug in the PICkit 4 into the USB cable, it doesn't enumerate, "USB device not recognised". If you switch ports, magically it does usually enumerate at that point, but MPLAB X won't recognise it. I've tried all sorts of combinations but regrettably other than trying another day, I'm buggered if I can get it to enumerate again, and be recognised by MPLAB X.

As well as being able to break you code at a specific point while it's running, the PICkit 4 also supports software breakpoints, great for those MCUs with single breakpoint capabilities.

On the PIC16F1509, programming is just as slow as other debuggers, so no real advantage there as I've seen with some other devices in the PIC24 and PIC32MZ series.

God knows why I bother with this shit, just like the ICD 4, it's an unfinished steaming pile of turd. The ICD 4 has had a few months to settle down but it's still useless for my purposes. I'd imagine the same problems will drag on for ever with PICkit 4 too.

[Howardlong]

It looks like the only way I can get the PICkit 4 to re-enumerate after removing it (or MPLAB X stops recognising it) is if I use the Hardware Boot Emergency Boot Firmware Recovery in the Debug menu of MPLAB X 4.15.

It show itself as a COM port first on VID/PID 04D8/9012, and the new firmware is installed, then it shows itself as 04D8/9017. In MPLAB X, new firmware is installed and it then shows itself as 04D8/9012 again, but as a Micorchip WinUSB device. I can then use it, until either I remove it or MPLAB X stops working with it again, whereupon I have to start again.

I also notice that it draws quite a bit of back current if you leave it connected to the DUT but unplug the USB cable (150 to 350mA).

Not sure if anyone else is having similar problems, or maybe I just have a crap example.

[mikeselectricstuff]

I also notice that it draws quite a bit of back current if you leave it connected to the DUT but unplug the USB cable (150 to 350A).

I assume you mean mA..?

On a quick test, I noticed it doesn't seem to tri-state its outputs after programming. ISTR ICD4 had an option for this so maybe there's an option I've not found yet

[Howardlong]

I also notice that it draws quite a bit of back current if you leave it connected to the DUT but unplug the USB cable (150 to 350A).

I assume you mean mA..?

On a quick test, I noticed it doesn't seem to tri-state its outputs after programming. ISTR ICD4 had an option for this so maybe there's an option I've not found yet

Yes, mA!

Do you have any problems in it re-enumerating after unplugging it from the USB after a programming or debug session?

Edit: I should add that typical quiescent current through the USB port is from 60mA to 160mA.

[mikeselectricstuff]

I also notice that it draws quite a bit of back current if you leave it connected to the DUT but unplug the USB cable (150 to 350A).

I assume you mean mA..?

On a quick test, I noticed it doesn't seem to tri-state its outputs after programming. ISTR ICD4 had an option for this so maybe there's an option I've not found yet

Yes, mA!

Do you have any problems in it re-enumerating after unplugging it from the USB after a programming or debug session?

Edit: I should add that typical quiescent current through the USB port is from 60mA to 160mA.

I've not used it in anger yet - too busy with real work to play with new tools.

[VEGETA]

I wonder if it allows programming AVR chips too. I hope it is supported in Arduino IDE so we could have one programmer to rule them all.

[stj]

no AVR support.

[Howardlong]

I also notice that it draws quite a bit of back current if you leave it connected to the DUT but unplug the USB cable (150 to 350A).

I assume you mean mA..?

On a quick test, I noticed it doesn't seem to tri-state its outputs after programming. ISTR ICD4 had an option for this so maybe there's an option I've not found yet

Yes, mA!

Do you have any problems in it re-enumerating after unplugging it from the USB after a programming or debug session?

Edit: I should add that typical quiescent current through the USB port is from 60mA to 160mA.

I've not used it in anger yet - too busy with real work to play with new tools.

Good job, it's an extensive rabbit hole all of its own that's for sure.

[VEGETA]

no AVR support.

Then why they bother doing a v4 of it?

Pickit3 was good enough on its own, so why pickit4? what will I gain from 4 that it is not in 3?

I really hoped to have one that does both while being from original manufacturer not some Chinese company.

Perhaps we should ask: Is it really possible to have one programmer for both AVR and PIC?

[mikeselectricstuff]

no AVR support.

Then why they bother doing a v4 of it?

Pickit3 was good enough on its own, so why pickit4? what will I gain from 4 that it is not in 3?

I really hoped to have one that does both while being from original manufacturer not some Chinese company.

Perhaps we should ask: Is it really possible to have one programmer for both AVR and PIC?

I have little doubt that AVR support will be addded at some point, as well as JTAG.
The main potential improvements are speed, not having to download new FW when changing device families, and the SD card for programmer-to-go mode. It also looks like there may be more protection on the ports.
I often use PTG mode for production - I send a preprogrammed PicKit 3 along with the test jig to the assembly house - if I need to update the FW  I need to either send another programmer or walk them through the non-trivial procedure to update ( which can be complicated by the fact that this process is flaky if you don't have target power at the time).
With the new one (in principle, assuming it works), I can just send them a file to stick on the SD card.

[Fire Doger]

Then why they bother doing a v4 of it?

Pickit3 was good enough on its own, so why pickit4? what will I gain from 4 that it is not in 3?

Speed

I really hoped to have one that does both while being from original manufacturer not some Chinese company.

Everyone could program their avr when ATMEL was separate manufacturer, why to bother to make all in one? As you saw pk4 and icd4 have issues, imagine if they had included avr and arm too....

Perhaps we should ask: Is it really possible to have one programmer for both AVR and PIC?

Everything is possible, the  question is if there is enough market for it to make higher profit by selling all in 1 solution.

[Howardlong]

I realise we all have our own way of debugging, and many will only be interested in its programming features. My use case includes programming, but most of the time I use them as part of my debugging workflow. Yes, I also add plenty of real time telemetry too while debugging, but I also use the debugging features a great deal too.

Its main features from a debugging perspective over the PICkit 3 are speed of programming (especially for larger devices), software breakpoints, and the ability to place arbitrary breakpoints while the DUT is running. (Note that I have seen little if any speed improvement in some PIC16 devices, but I certainly have with PIC24 and PIC32).

The software breakpoint thing is especially useful for devices which only have a limited hardware breakpoint capabilities: some lower end devices only have a single hardware breakpoint for example.

[SiliconWizard]

If you compare it with the performance of the old MPLAB non-X, you wonder what “progress” is in the minds of some engineers.

I suspect this may not be any engineer's decision.

A big factor, unfortunately, which pushes a lot of companies to switch to Java solutions, apart from the hype factor (which is starting to vanish actually) is the difficulty to hire young software engineers who can develop in anything else than Java. It's the number one factor IMO for managers.

[mikeselectricstuff]

According to the Microchip forum

We are hoping to have PICkit 4 OTG supported by the Aug release of MPLAB X.

***ing AUGUST ? 

Obviously someone has decided designer-case wankery is more important than usefulness. Idiots.

[Warhawk]

those of us working in semi business know that the perspective has already changed and marketing is more than any engineering. Welcome to engineering in the 21st century.
The worst thing is that it works. When you see the profile of a typical college graduate, his/her skills and knowledge of electronics, you will find out why.

[KL27x]

if I need to update the FW  I need to either send another programmer or walk them through the non-trivial procedure to update ( which can be complicated by the fact that this process is flaky if you don't have target power at the time).
With the new one (in principle, assuming it works), I can just send them a file to stick on the SD card.

With the PK2, I removed the EEPROM chips and wired them to a 5 pin female pin header. I just made up a few dozen EEPROM boards with male header that plug into the socket. This works great on PK2, because all of the P2G data is on the EEPROM, including target power, device, MCLR, etc. The only thing that is not stored on the EEPROMS, AFAIK, is whether the PK2 should boot up to P2G mode or not. Once set for P2G, the EEPROM board is all I need to swap or send. (I figured this out by trial). I never got around to trying this on PK3, so I don't know what problems could arise.

AFAIK, the PM3 can do what you want, right now. But of course if costs a heck of a lot more than a PK3. If you have a long-term partner, this might be worth consideration.

the non-trivial procedure to update

It's nontrivial, even for me, and I do it many times a month, on average. PK2 is so much faster and far less click-maze routine. Unfortunately, it looks like Microchip is patting themselves on the back for the PK3 and might be hellbent to make even more "improvements," rather than undoing some of the ones they already made. When I read the PK4 continues the tradition of using their own USB driver, I figured it would just be the next evolution of making bugs and pissing people off. The enumeration problems that Howardlong has described are pretty much how PK3 always acted for me.

I guess you have some projects where you don't do the whole bootloader flashed by the factory, and panels of devices updated via mousebite, thing?

I have a simple device for quickly flashing bare chips. Fast and easy enough that I use ICSP pads/interface only as emergency backup. Still wondering if there's any need for this invention in the modern world. Customs can hit you sending micros back and forth to China, of course, but I do a lot of my own PCB assembly.

[nomadd]

***ing AUGUST ? 

***ing MPLAB-X? 

[NorthGuy]

Obviously someone has decided designer-case wankery is more important than usefulness. Idiots.

Not at all. Appearance is everything. Nice case will bring you more sales than good functionality. When you look at the mice case, it awakens desires within you and you buy. Once you discover the functionality flaws, you just learn to live with them. Without a nice case, you wouldn't buy and would never know anything about functionality.

[cv007]

Appearance is everything

That may be true for consumer items to a degree, but I don't think it applies in this case. You are not buying PicKitX because of its looks, its because you have and want to program a pic and there is no other option from the manufacturer of that chip. Its not like shopping for a computer accessory where there are dozens of choices. What they produce is what we get. They could make them in awkward round cases, and people would still buy them

[NorthGuy]

Appearance is everything

That may be true for consumer items to a degree, but I don't think it applies in this case. You are not buying PicKitX because of its looks, its because you have and want to program a pic and there is no other option from the manufacturer of that chip. Its not like shopping for a computer accessory where there are dozens of choices. What they produce is what we get. They could make them in awkward round cases, and people would still buy them

This is a very narrow view of appearance. Appearance is everything which is not related to actual usability. For some it is a metal box, for you it is Microchip logo (although I can imagine people abandoning Microchip because the sky over STM32 seems brighter to them), for Mike it may be FPGA and powerful ARM32 inside. Regardless of what it is, marketers manipulate appearance, test responses and move in the direction where the profit is maximized. When you buy it, you endorse the whole complex of appearances, so what you buy is likely to continue and what you don't buy is likely to be eliminated. This process has nothing to do with engineering. If it was, you would never see PICkit3 replacing PICkit2 (which had better design), or MPLAB X replacing MPLAB 8.

[Howardlong]

One of the machines I was trying PICkit 4 on, without much luck, was a Mac but running Windows 10 natively (all my tests thus far have been on Windows 10 x64 machines).

I tried it last night in OS X, and in the limited testing I did it did seem to work, it was a far cleaner test.

[JPortici]

***ing AUGUST ? 

in the meantime i hope they will focus on adding parts support. ALL the PICs I use are still not supported or beta supported. (both on ICD4 and PK4)

[cv007]

When you buy it, you endorse the whole complex of appearances, so what you buy is likely to continue and what you don't buy is likely to be eliminated. This process has nothing to do with engineering.

I think the only endorsement taking place is some prefer their chips. We are stuck buying their programmer/debugger, whatever appearance they come up with. If they really wanted the appearance factor, they should have used an anodized aluminum case of various colors, and dropped to a very capable mz cpu to make up the difference (if they used a mz cpu, I could then see them using that for all future curiosity boards, but I don't seem them slapping that sam on them- so many new users will still be stuck with the pk3 version of pkob).

I think the only thing they have going for them in the programmer/debugger department, is existing customers will always be willing to buy the next version with the hopes of something better. Maybe the pk4 is that better version, and will be more reliable than the pk3. We'll see.

Like always, I could be wrong.

[NorthGuy]

I think the only endorsement taking place is some prefer their chips. We are stuck buying their programmer/debugger, whatever appearance they come up with ... Maybe the pk4 is that better version, and will be more reliable than the pk3. We'll see.

Many people are still using PICkit2. They even go great distance to build support for new parts, because they prefer it.

[mikeselectricstuff]

I think the only thing they have going for them in the programmer/debugger department, is existing customers will always be willing to buy the next version with the hopes of something better. Maybe the pk4 is that better version, and will be more reliable than the pk3. We'll see.

I've never had any major issues with PK3, real or clones - only reason to look at PK4 was speed and SD functionality ( and curiosity..)

[Howardlong]

I think the only thing they have going for them in the programmer/debugger department, is existing customers will always be willing to buy the next version with the hopes of something better. Maybe the pk4 is that better version, and will be more reliable than the pk3. We'll see.

I've never had any major issues with PK3, real or clones - only reason to look at PK4 was speed and SD functionality ( and curiosity..)

“Connection failed” is common with PICkit3, in Windows 10 I had it just this week, again.

There’s a registry fix for Windows 10 that I use:

HKLM\System\CurrentControlSet\Enum\USB\VID_04D8&PID_900A

EnhancedPowerManagementEnabled value to 0

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

[Howardlong]

I did start to tell a long sorry tale about how I figured this one out, as far as sniffing the bus with a scope etc, but to save you from the anecdote, it turns out there is a design flaw relating to the PCB lands and the Micro B receptacle. For some cables, the D- line was getting shorted to ground, but only when a micro B cable was inserted, and only with some cables, including the one provided, which rather unhelpfully in this case you are warned to use and no other. When it was working, I happened to be using a different cable I had lying around that did work as it had slightly different physical characteristics..

To fix, lift the USB Micro B receptacle, pop in a carefully crafted piece of Kapton tape partially covering about a third of the five pin lands (see second pic below). Resolder the USB Micro B and check pin 2 and pin 5 (or the shield) are not shorting when an offending USB cable is inserted.

[stj]

interesting.
it's also the same type of connector as the kindle-fire uses.
they are known to fail relativly quickly if you insert and remove the cable a lot.

i have a bag of them for repair work, if anybody needs a link, there is a seller on AE doing them for about 15c each!!

[MT]

God knows why I bother with this shit, just like the ICD 4, it's an unfinished steaming pile of turd.

The eternal unanswered question to the supremebeeings (God) creation.

[brizzo]

Received marketing email from Microchip couple weeks ago, learned PICKIT 4 was being offered. Ordered a kit, received yesterday. Popped it open, surprised to see PIC32 and ARM branding on the same chip. Figured eevblog would be good place to see if anyone else had opened one up and posted pics. Seems there has been a change recently in the part markings...?!

Atmel SAM E70 is now Microchip PIC32CZ series ?!

[NorthGuy]

Atmel SAM E70 is now Microchip PIC32CZ series ?!

Already here. I believe other SAMs will be renamed to PIC32CM and PIC32CX. It's not hard to figure out what happens to PIC32MM, PIC32MX and PIC32MZ afterwards.

[stj]

already had problems myself with the renaming,
spent ages on RS website trying to find an AVR chip till i changed the filter to include "microchip"!!   
 

[Mr. Scram]

I finally bought that Atmel ICE I've been eyeing for ages, so of course Microchip releases a more capable device for half the price. 

[cv007]

It's not hard to figure out what happens to PIC32MM, PIC32MX and PIC32MZ afterwards.

They rename them to ATSAM-XX?

[Howardlong]

I finally bought that Atmel ICE I've been eyeing for ages, so of course Microchip releases a more capable device for half the price. 

If you’re referring to the PICkit4, frankly its support is so unfinished I’ve found it’s the exception rather than the rule when it works.

I’ve attempted to use it on a dozen or so different devices from PIC12 to PIC32 and everything in between, and most of the time I find I have an unsupported chip. The rest of the time certain scenarios don’t work, for example debugging the processor at full speed or using a debug header. The ICD4 is only very marginally better in terms of support than the PICkit4.

If the ICD4 or the PICkit4 were your only debuggers you’d be well and truly f###ed off. I would stick to the ICD3/RealICE/PICkit3 for now for PICs.

I don’t do much Atmel stuff but I did end up with a Dragon that I bought for a specific project, only to find out later it didn’t work with some other Atmel devices, so I also went with the Atmel ICE that I should’ve bought all along.

It’s a frustrating and recurring story, I must have at least a couple of dozen debuggers of one sort or another in various drawers.

[JanJansen]

Can i also change the EnhancedPowerManagementEnabled value to 0 somewhere in windows XP ?
Maybe then the newer MPLAB ( from v3 ) will work also on XP then ?
thanks

What do you need the newer MPLAB for anyways ?, all compilers work with v2 perfectly in XP.

[Howardlong]

What do you need the newer MPLAB for anyways ?, all compilers work with v2 perfectly in XP.

Pretty sure there will be some prerequisite somewhere, if it's not the chip or debugger support it'll be Harmony.

[JPortici]

newer PK/ICD firmware, which is bundled with MPLAB X?

i think support for PK4/ICD4 is only from 4.0 or something

[Howardlong]

newer PK/ICD firmware, which is bundled with MPLAB X?

i think support for PK4/ICD4 is only from 4.0 or something

4.15, but neither are properly supported by any stretch.