Dwarf: A PICKit 2 GUI for Linux

Too lazy to type out the commands every time I wanted to do something to my project and with a couple of days spare before parts arrived, I decided that what I really needed was a little GUI to run the commands for me. I've used gpasm as my assembler (from GNU PIC Utilities) and the PK2CMD program hosted on the Microchip Website as the back end for this application.

Essentially this is a very simple Python powered GTK interface that executes a number of the most common command line instructions used in PIC development when you click one of the buttons. It provides some feedback to the user about how the command went.

Checkout the documentation at the end of this page, and try out the application.

dwarf.pdf91.3 KB
dwarf.tgz94.75 KB
Free tagging: 


I just tried your Dwarf GUI for the pk2cmd and as far as I can tell it seems to work okay. It would be nice to have some tooltips for the icons though. Still, until I find something that has a few more bells and whistles this will do nicely.

Never been able to get it to work.
Does no part found mean that it can't see the USB port?
lsusb reports:
Bus 002 Device 004: ID 0b97:7762 O2 Micro, Inc. Oz776 SmartCard Reader
Bus 002 Device 003: ID 0b97:7761 O2 Micro, Inc. Oz776 1.1 Hub
Is this it?
Is anyone there?

Oops! Sorry, forgot to load GPUtils.
It stops at "Autodetect Failed" though!
It's slow going. It's now 2:15AM and I'm still trying..

My goof - again. Getting tired (3:30AM)
I eventually realised I should actually hook up a chip.
One question though.: Is there any way OSCCAL can be displayed. I don't know if this application takes a note of OSCCAL and checks it after programming..

Can a facility be added to read the contents of a chip into memory?, so it can be copied onto another chip, taking care not to copy the OSCCAL, of course.

Is there anyone alive out there? Am I the only person on this planet with an interest in Dwarf?
Anyway, managed to add another icon to get the app to read and store the contents of the PIC to desktop. Very basic but works quite well.
Does anyone (if there is anyone out there) know if pk2cmd handles the OSCCAL bytes safely?
Does anyone have a python app to read and maybe even recalibrate OSCCAL if it gets wiped? That would be handy! I'd even have a go at adding that feature into Dwarf if the originator has moved to higher planes, or just buggered off somewhere..


You're not the only one tinkering with this. I don't think I can help with your issue, but perhaps you could enlighten me a bit?
I have a PIC32MX460F512L on an Explorer16 board with a 'ported' PICkit2 firmware on the Explorer16. With the Windows PK2 GUI utility everything is fine.

In linux though, dwarf and pk2cmd complain about "Configuration Memory Errors", and pk2cmd says I need to erase before I program... which I tried by including "-E"... and no luck. Dwarf's auto-detect does find my MX460, but Manual detection results in "Warning: {unknown device} found." Dwarf does let me start and stop a program already flashed on my MX460, so that's... nice... I guess.

So I have some ideas. Even the Win utility warned me that not all configuration bits were explicitly set, so maybe I should do that even where the defaults are appropriate. I tried erasing as a separate step but that didn't help... maybe there's a sequence I can discover to get that to work.

I suppose my issue might be with using pk2cmd properly... but then again the whole point of the GUI is to abstract-away those details.

Anyway, let me know if you have any ideas.

Sorry, I haven't checked this site for some time.

I wrote the Dwarf utility to support 8bit PICs using the PK2CMD software (which I didn't write). The fact that it's working in any way with PIC32 is amazing and certainly not tested.

I would have liked to strip apart the code for the PK2CMD software and re-compile it with python bindings for a much tighter integration with the GUI but it doesn't seem permissible with the license though.

The project has come to a halt more or less because of the arrival of MPLAB-X which is running on Linux with support for PICKit 2 and 3, that's what I used for my last project and probably will be using in future.

The current version of the code has got a read device memory option I think, and is on GitHub https://github.com/hairymnstr/dwarf if you want to fork and add features I'm happy with that, if you want to contribute back to my repository let me know and I'm happy to merge your additions back into my own repository. Personally I haven't got time to work on this at the moment, I have many more pressing demands on my free time.

OSCCAL: using -U on the command line should program it using PK2CMD, there's no way to do this in the UI. It should be fairly trivial to add this feature. I'm not sure how/if you can read the value, maybe by reading the configuration memory you can see it?

The PIC32MX460F512L should be supported by PK2CMD, it's possible that Dwarf isn't handling the device name properly because of some assumptions I made about 8bit PIC naming but I've not read the source.

Thanks for the interest.


My suspicion about unspecified configuration words was correct. I found a microchip forum post confirming that explicitly setting all configuration bits fixes the "Configuration Memory Errors" problem I was having.

With that fixed, Dwarf has no problem handling my MX460 through the custom PK2 firmware on my EX16. Between that (and other hacks to the EX16 (http://www.paintyourdragon.com/?p=51)), along with a Wi-Fi PICtail plus card, I now have a really portable (and lap-friendly) dev platform. Just the EX16 board and a single USB cable... slick.

So thanks very much for your efforts with Dwarf. I think it's still a worthwhile endeavor for the products "in the chasm" that are supported by the PICkit 2 GUI and command line utilities, but not by MPLAB8/X. Case in point: MPLABX detects the quasi-PK2 on my EX16, but won't let me flash the MX460 with it, and this hurdle is what led me to Dwarf. If I was a python guy I would seriously consider helping out... maybe someday.


Hi Nathan.
Thanks for getting back to us.
I had no luck with MPLABX, which is why I came here.
You are correct. Dwarf 0.2 Beta 1 does have a hex dump facility.
OSCCAL is apparently the last 4 bytes of the dump, and everything is fine if I actually have to force OSCCAL with a -U as the idea is to leave it alone otherwise the PIC doesn't work.

Hi again Nathan.
The PIC's that I will be programming are extremely likely to have a previous program already in them.
The PK2CMD to erase is E (I know that much).
Is it possible to add that into the python script?

Lines 416 to 429 read:

def program(self, hexfile):
opts = []
opts.append("-P" + self.device)
opts.append("-F" + hexfile)
If I add an extra line:


would that work or is life more complicated?

The -M option does erase, program and verify, the -E option is just for erasing a device with no write option, you should rarely need to use -E. If it does anything adding it to the options there it will add to the wear and tear on your flash memory but probably nothing else. See this post for a similar question: http://www.microchip.com/forums/tm.aspx?m=451434

Thanks Nathan.
I asked because the first chip I programmed didn't work. It turns out that there is a fault with the original hex file downloaded from the MERG website, so I was barking up the wrong tree. I loaded a different version and it works fine.
Somebody else's goof this time - makes a change...

Add new comment

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
This question is for testing whether you are a human visitor and to prevent automated spam submissions. Comments are still moderated just to remove advertising, your opinions/comments will always be approved.
Enter the characters shown in the image.