What Microchip hides from Dave after his Pickit3 video, yes new Pickit4 :) - Page 1
Forum section: electronics / general

author: ucanel
author_rank: Regular Contributor
timestamp: February 27, 2018, 06:44:06 pm
content: http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=PG164140I 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 thenew Pickit4, maybe along with uCalc uWatch or uSupply.There is a chance that microchip already send a Mailbagjust 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

author: thm_w
author_rank: Super Contributor
timestamp: February 27, 2018, 08:53:44 pm
content: 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.Quote"PIC MCU" apparently includes AVR and SAM ARM mcu's which isreallyconfusing. But it sounds like we might be lucky and get a lower cost atmel SWD programmer (for commercial use, jlink is cheaper for edu):Quotehttp://ww1.microchip.com/downloads/en/DeviceDoc/00002618A.pdf

author: stj
author_rank: Super Contributor
timestamp: February 28, 2018, 01:39:00 am
content: it even comes with stickers!! /sarcbut seriously, no schematic yet - so not an open design?

author: NiHaoMike
author_rank: Super Contributor
timestamp: February 28, 2018, 05:36:44 am
content: 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!Quote from: thm_w on February 27, 2018, 08:53:44 pmI'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!)

author: KL27x
author_rank: Super Contributor
timestamp: February 28, 2018, 05:48:43 am
content: I hope they manage to keep the bloat and bugs out of this version.QuoteIf 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.

author: hans
author_rank: Super Contributor
timestamp: February 28, 2018, 09:12:43 am
content: 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.

author: JPortici
author_rank: Super Contributor
timestamp: February 28, 2018, 09:39:55 am
content: Quote from: hans on February 28, 2018, 09:12:43 amme too!of coursethere's no support (yet) for almost all the parts that i use(dsPICs with codeguard) but the feature list is interesting (they added JTAG!)

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: February 28, 2018, 09:49:25 am
content: Just ordered one...

author: jpanhalt
author_rank: Super Contributor
timestamp: February 28, 2018, 09:55:20 am
content: Notably absent from the announcement is whether it will be compatible with MPLAB 8.92. I suspect it will not be.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: February 28, 2018, 09:57:26 am
content: I can't imagine for a second that it would be compatible with MPLAB 8.x

author: tszaboo
author_rank: Super Contributor
timestamp: February 28, 2018, 10:35:45 am
content: Quote from: NiHaoMike on February 28, 2018, 05:36:44 amActually, I think they should release something that would support all AVR/ARM/PIC micro in their lineup. After all this is mostly software.

author: JPortici
author_rank: Super Contributor
timestamp: February 28, 2018, 12:35:43 pm
content: 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.htmlQuote

author: Maxlor
author_rank: Frequent Contributor
timestamp: February 28, 2018, 12:41:16 pm
content: If you're ordering from microchipdirect.com, the code EW2018DT should give you 25% off.

author: JanJansen
author_rank: Frequent Contributor
timestamp: February 28, 2018, 04:40:38 pm
content: Quote from: hans on February 28, 2018, 09:12:43 amYou 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.

author: KL27x
author_rank: Super Contributor
timestamp: February 28, 2018, 07:35:35 pm
content: ^ 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: March 02, 2018, 11:44:07 am
content: 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 endSimilar wanky light-guide to ICD4USB Micro8 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.

author: hans
author_rank: Super Contributor
timestamp: March 02, 2018, 11:55:53 am
content: Well, it should support 5 and 6-pin ICSP interfaces:QuoteQuoteAlso, the product is still in progress:QuoteCuriously 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.

author: igendel
author_rank: Frequent Contributor
timestamp: March 02, 2018, 11:57:39 am
content: Quote from: mikeselectricstuff on March 02, 2018, 11:44:07 amThe 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

author: Maxlor
author_rank: Frequent Contributor
timestamp: March 02, 2018, 01:07:47 pm
content: Quote from: mikeselectricstuff on March 02, 2018, 11:44:07 amThe 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?

author: hans
author_rank: Super Contributor
timestamp: March 02, 2018, 01:53:53 pm
content: 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...

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: March 02, 2018, 02:09:45 pm
content: 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 drawI've not yet found any info on the SD card functionality.No more time to play

author: BrianHG
author_rank: Super Contributor
timestamp: March 02, 2018, 02:42:18 pm
content: Quote from: mikeselectricstuff on March 02, 2018, 11:44:07 amAre they seriously expecting that button and squeezing that case to last thousands of cycles.

author: tszaboo
author_rank: Super Contributor
timestamp: March 02, 2018, 08:08:06 pm
content: The Pickit 4 has a Atmel SAM microcontroller in it.Oh the irony...

author: KL27x
author_rank: Super Contributor
timestamp: March 02, 2018, 10:00:41 pm
content: QuoteI 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).QuoteThis 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: March 02, 2018, 10:03:52 pm
content: Quote from: KL27x on March 02, 2018, 10:00:41 pmI 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 thisQuotePlenty showing in stock at Microchip direct

author: KL27x
author_rank: Super Contributor
timestamp: March 02, 2018, 10:10:28 pm
content: 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.QuoteAt 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.

author: Howardlong
author_rank: Super Contributor
timestamp: March 07, 2018, 10:31:10 pm
content: [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 isQuoteOS 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: March 07, 2018, 11:24:26 pm
content: Quote from: Howardlong on March 07, 2018, 10:31:10 pmI'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.

author: Howardlong
author_rank: Super Contributor
timestamp: March 08, 2018, 01:06:45 am
content: 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.

author: josip
author_rank: Regular Contributor
timestamp: March 08, 2018, 07:56:24 am
content: Quote from: Howardlong on March 07, 2018, 10:31:10 pmAnd what is the size of that blinky example? To put programming rate in KByte/sec.

author: JPortici
author_rank: Super Contributor
timestamp: March 08, 2018, 08:41:23 am
content: Quote from: Howardlong on March 08, 2018, 01:06:45 amprogramming-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

author: josip
author_rank: Regular Contributor
timestamp: March 08, 2018, 08:57:31 am
content: Quote from: JPortici on March 08, 2018, 08:41:23 amBecause 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)?

author: hans
author_rank: Super Contributor
timestamp: March 08, 2018, 09:10:30 am
content: 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.

author: JPortici
author_rank: Super Contributor
timestamp: March 08, 2018, 09:17:53 am
content: Quote from: josip on March 08, 2018, 08:57:31 amI 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

author: josip
author_rank: Regular Contributor
timestamp: March 08, 2018, 09:24:28 am
content: Quote from: hans on March 08, 2018, 09:10:30 amIf 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.Quote from: hans on March 08, 2018, 09:10:30 amI 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.

author: josip
author_rank: Regular Contributor
timestamp: March 08, 2018, 09:33:51 am
content: Quote from: JPortici on March 08, 2018, 09:17:53 amThis is too slow for me, but I am not familiar with PIC and it's flash memory characteristics.For example,20 years oldMSP430F2xx devices are with flash memory that is limited to50 KByte/secwriting rate.

author: ggchab
author_rank: Frequent Contributor
timestamp: March 08, 2018, 09:44:39 am
content: Quote from: Maxlor on February 28, 2018, 12:41:16 pmThank you. I just ordered a pickit4 and the code worked perfectlyI 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 ...

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: March 08, 2018, 10:16:10 am
content: Quote from: JPortici on March 08, 2018, 08:41:23 amIt is somewhat dependent on the part and the code size - I've seen from 2 to about 20 secs

author: Howardlong
author_rank: Super Contributor
timestamp: March 08, 2018, 10:37:56 am
content: Quote from: ggchab on March 08, 2018, 09:44:39 amI 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

author: KL27x
author_rank: Super Contributor
timestamp: March 08, 2018, 10:36:34 pm
content: QuoteI 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 08, 2018, 11:28:09 pm
content: Quote from: KL27x on March 08, 2018, 10:36:34 pmThere 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.

author: cv007
author_rank: Frequent Contributor
timestamp: March 09, 2018, 02:30:42 am
content: 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).

author: KL27x
author_rank: Super Contributor
timestamp: March 09, 2018, 08:47:42 am
content: 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.

author: josip
author_rank: Regular Contributor
timestamp: March 09, 2018, 08:50:10 am
content: Quote from: KL27x on March 08, 2018, 10:36:34 pmMany 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.aspxQuoteWhere 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...QuoteThat 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).

author: stj
author_rank: Super Contributor
timestamp: March 09, 2018, 11:45:05 am
content: 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 09, 2018, 02:08:03 pm
content: Quote from: KL27x on March 09, 2018, 08:47:42 amSure. 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.

author: Howardlong
author_rank: Super Contributor
timestamp: March 09, 2018, 02:27:00 pm
content: 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!

author: cv007
author_rank: Frequent Contributor
timestamp: March 09, 2018, 06:38:38 pm
content: QuoteAn 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 09, 2018, 08:30:01 pm
content: Quote from: cv007 on March 09, 2018, 06:38:38 pmDouble? 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.

author: cv007
author_rank: Frequent Contributor
timestamp: March 09, 2018, 10:29:22 pm
content: QuoteI was referring to MCHP, so I set the bar low with 'double' (and I also said without much effort).QuoteI 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.

author: Howardlong
author_rank: Super Contributor
timestamp: March 09, 2018, 10:41:33 pm
content: 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 10, 2018, 12:10:07 am
content: Quote from: Howardlong on March 09, 2018, 10:41:33 pmI 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.

author: josip
author_rank: Regular Contributor
timestamp: March 10, 2018, 08:29:28 am
content: Quote from: cv007 on March 09, 2018, 06:38:38 pmSimilar 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) = 1165and with 461.5 kHz flash frequency, flash writing rate will be49.5KByte/sec (these are self program numbers).Benchmark (write command) for my flasher with this target device connected, on Win / Linux / OS X, will show48.3KByte/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.Quote from: NorthGuy on March 09, 2018, 08:30:01 pmAnd 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.

author: Howardlong
author_rank: Super Contributor
timestamp: March 13, 2018, 10:28:06 pm
content: 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.

author: Howardlong
author_rank: Super Contributor
timestamp: March 14, 2018, 11:40:21 pm
content: 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: March 15, 2018, 12:11:55 am
content: Quote from: Howardlong on March 14, 2018, 11:40:21 pmI 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

author: Howardlong
author_rank: Super Contributor
timestamp: March 15, 2018, 12:14:18 am
content: Quote from: mikeselectricstuff on March 15, 2018, 12:11:55 amYes, 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: March 15, 2018, 12:23:46 am
content: Quote from: Howardlong on March 15, 2018, 12:14:18 amI've not used it in anger yet - too busy with real work to play with new tools.

author: VEGETA
author_rank: Super Contributor
timestamp: March 15, 2018, 06:48:46 am
content: 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.

author: stj
author_rank: Super Contributor
timestamp: March 15, 2018, 09:25:05 am
content: no AVR support.

author: Howardlong
author_rank: Super Contributor
timestamp: March 15, 2018, 09:32:36 am
content: Quote from: mikeselectricstuff on March 15, 2018, 12:23:46 amGood job, it's an extensive rabbit hole all of its own that's for sure.

author: VEGETA
author_rank: Super Contributor
timestamp: March 15, 2018, 10:30:42 am
content: Quote from: stj on March 15, 2018, 09:25:05 amThen 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?

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: March 15, 2018, 10:40:07 am
content: Quote from: VEGETA on March 15, 2018, 10:30:42 amI 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.

author: Fire Doger
author_rank: Regular Contributor
timestamp: March 15, 2018, 10:59:29 am
content: Quote from: VEGETA on March 15, 2018, 10:30:42 amSpeedQuoteEveryone 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....QuoteEverything is possible, the question is if there is enough market for it to make higher profit by selling all in 1 solution.

author: Howardlong
author_rank: Super Contributor
timestamp: March 15, 2018, 11:05:07 am
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 15, 2018, 02:19:58 pm
content: Quote from: Howardlong on March 09, 2018, 10:41:33 pmI 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: March 16, 2018, 07:13:53 pm
content: According to the Microchip forumQuote***ing AUGUST ?Obviously someone has decided designer-case wankery is more important than usefulness. Idiots.

author: Warhawk
author_rank: Frequent Contributor
timestamp: March 16, 2018, 10:14:14 pm
content: 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.

author: KL27x
author_rank: Super Contributor
timestamp: March 16, 2018, 10:59:41 pm
content: QuoteWith 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.QuoteIt'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.

author: nomadd
author_rank: Contributor
timestamp: March 17, 2018, 12:38:40 am
content: Quote from: mikeselectricstuff on March 16, 2018, 07:13:53 pm***ing MPLAB-X?

author: NorthGuy
author_rank: Super Contributor
timestamp: March 17, 2018, 12:46:42 am
content: Quote from: mikeselectricstuff on March 16, 2018, 07:13:53 pmNot 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.

author: cv007
author_rank: Frequent Contributor
timestamp: March 17, 2018, 03:52:10 am
content: QuoteThat 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

author: NorthGuy
author_rank: Super Contributor
timestamp: March 17, 2018, 04:49:40 am
content: Quote from: cv007 on March 17, 2018, 03:52:10 amThis 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.

author: Howardlong
author_rank: Super Contributor
timestamp: March 17, 2018, 06:36:49 am
content: 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.

author: JPortici
author_rank: Super Contributor
timestamp: March 17, 2018, 10:41:44 am
content: Quote from: mikeselectricstuff on March 16, 2018, 07:13:53 pmin 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)

author: cv007
author_rank: Frequent Contributor
timestamp: March 17, 2018, 02:40:13 pm
content: QuoteI 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 17, 2018, 04:00:24 pm
content: Quote from: cv007 on March 17, 2018, 02:40:13 pmMany people are still using PICkit2. They even go great distance to build support for new parts, because they prefer it.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: March 17, 2018, 04:07:07 pm
content: Quote from: cv007 on March 17, 2018, 02:40:13 pmI've never had any major issues with PK3, real or clones - only reason to look at PK4 was speed and SD functionality ( and curiosity..)

author: Howardlong
author_rank: Super Contributor
timestamp: March 17, 2018, 11:17:33 pm
content: Quote from: mikeselectricstuff on March 17, 2018, 04:07:07 pm“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_900AEnhancedPowerManagementEnabled value to 0http://www.microchip.com/forums/m883106.aspx

author: Howardlong
author_rank: Super Contributor
timestamp: March 19, 2018, 07:48:41 pm
content: 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 withsomecables, 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 thatdidwork 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.

author: stj
author_rank: Super Contributor
timestamp: March 19, 2018, 11:53:32 pm
content: 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!!

author: MT
author_rank: Super Contributor
timestamp: March 20, 2018, 01:19:01 am
content: Quote from: Howardlong on March 13, 2018, 10:28:06 pmThe eternal unanswered question to the supremebeeings (God) creation.

author: brizzo
author_rank: Newbie
timestamp: May 01, 2018, 09:37:56 am
content: 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 ?!

author: NorthGuy
author_rank: Super Contributor
timestamp: May 01, 2018, 01:19:24 pm
content: Quote from: brizzo on May 01, 2018, 09:37:56 amAlready 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.

author: stj
author_rank: Super Contributor
timestamp: May 01, 2018, 02:10:36 pm
content: 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"!!

author: Mr. Scram
author_rank: Super Contributor
timestamp: May 01, 2018, 02:13:42 pm
content: 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.

author: cv007
author_rank: Frequent Contributor
timestamp: May 01, 2018, 02:14:19 pm
content: QuoteThey rename them to ATSAM-XX?

author: Howardlong
author_rank: Super Contributor
timestamp: May 01, 2018, 06:13:09 pm
content: Quote from: Mr. Scram on May 01, 2018, 02:13:42 pmIf 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.

author: JanJansen
author_rank: Frequent Contributor
timestamp: May 03, 2018, 03:47:04 pm
content: 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 ?thanksWhat do you need the newer MPLAB for anyways ?, all compilers work with v2 perfectly in XP.

author: Howardlong
author_rank: Super Contributor
timestamp: May 04, 2018, 02:33:09 pm
content: Quote from: JanJansen on May 03, 2018, 03:47:04 pmPretty sure there will be some prerequisite somewhere, if it's not the chip or debugger support it'll be Harmony.

author: JPortici
author_rank: Super Contributor
timestamp: May 04, 2018, 03:33:56 pm
content: newer PK/ICD firmware, which is bundled with MPLAB X?i think support for PK4/ICD4 is only from 4.0 or something

author: Howardlong
author_rank: Super Contributor
timestamp: May 04, 2018, 05:56:24 pm
content: Quote from: JPortici on May 04, 2018, 03:33:56 pm4.15, but neither are properly supported by any stretch.