PIC handheld debugger - how I did it
Hi all friends,
This will be a longer story, story about writing a lots of code, dreaming, sleepless nights, building a complete handheld PIC debugger (working on the same basis as PicKit2 or ICD2) and also a story about how Microchip thought that their customer is idiot. Unlike most of posts, it will not include any complain or ask for a help with some kind of problem, just reading for interested ones...
...for a long time, I dreamt about a small device, which could be programmed in some programming language, a device which could be taken everywhere, that would fit my hand portable and independent from electrical network, etc. While there are lots of PDA class computers, smart (whatever it means) phones and small netbooks, which could serve for this, all that doesn’t exhibit one important feature - to be DIY hand made. That time (I was maybe 14 or 15 years old) I had no clue about microcontrollers nor microprocessors so all those thoughts remained just dreams.
Now things slightly changed. While studying university I did a small device, consisting of 8052 basic module (compressed into one 89C51RD2 device, really single-chip solution) with 18F2620 with LCD and keypad display serving as terminal, plus some other components (PSU, RS232 interface etc) forming a small computer-like device, able to program itself in BASIC. A lot of people asked me, what is it good for... well, for nothing. There is no real reason for doing something like that, except of good feeling after completing a device, which really works, stretching a brain, hobby or whatever you call it. But after all, I felt unsatisfied with that and want something more.
I took a 18F2620 (yes, my favorite, when it comes to 18F family), added a keypad and display and wrote a small program, which enabled me to change a portion of RAM – all done in means of hexadecimal numbers, then I could burn this image into FLASH and jump at this address – sort of monitor program, like WOZMON for Apple1 computer. Writing in machine code could be interesting as well as annoying and slow, so I felt something like small assembler would be great. First I looked for assembler, which could fit into a few kilobytes of RAM, but how wrong I was! I decided to write my own. I won’t bother you with this task, it took me a few weeks to write a small assembler for 18F devices, which could fit into RAM of PIC18F2620, after leaving a 2kB of RAM for program buffer! It was a pretty poor-featured assembler, but worked after all.
Well, nice tool-chain on chip... editor, assembler and burner. Debugger would be nice, but who knows, how to? Except of Microchip guys, probably nobody. There is
NO specification for on-chip debug module contained in every single PIC18.
Fortunately, in that time I found book, which was miraculous for me... Coin-Cell-Powered Embedded design by John Peatman. To be honest, most exciting for me wasn’t that designs, covered in book, as I found it quite usual for me, but the mention about debug mode in monitor (QwikBug), which serves as basis for those project really got me. I downloaded sources and started to study. I was unsure about a few things, so I nicely asked Microchip, whether they could send me a description of debug mode for 18F PICs. First of all they treated me like a complete idiot (just got response that resources needed by ICD2 debugger can be found somewhere in help – ie. not what I asked) and when I asked again, they responded that they don’t have any debugging specification and my support ticked was closed. Great support, I must admit! Well, help yourself, little man.
So I returned back into studying sources for QwikBug, disassembling hex-binaries from PicKit2 directory (debug executives for various PICs) and ICD2 as well, studying sources for PicKit2, and .xml files. I also wrote to John Peatman, who gave me a few valuable comments. This was still incomplete source. After a long, long and again long days and nights spent with this and after a unbelievable amount of experiments I finally got that damned (see
Note 1, bottom) PIC to enter debug mode by itself.
Then I found out that debugging PIC by itself wouldn’t be easy, and if it would be easy, then it wouldn’t be useful and if it even would be useful, it will not be useful very much. So I decided to decline my way of single-chip tool-chain and soldered another PIC into my breadboard, as a slave device.
Then started another long story, consisting of writing debug executive for slave PIC and complete debug engine for master PIC. It took me a lot of time to get functional couple debugger-target and I must admit that this, along with reverse engineering of debug specifications for PIC18 was the most challenging task I ever did in my short life (25 years old now) – I started with a few incomplete information all around and finished with working system.
Then came some small “cosmetic” changes, like porting whole editor-assembler-burner-debugger into dsPIC33FJ128GP802 – just because of more RAM, more horse power (for assembler and debugger), adding a bigger display, writing a GUI for debugger and so on. After all this my new PIC18 debugger is done. If you wish to know, how it looks and how it works, look at this PDF
http://zbernica.chytrak.cz/files/hdm_desc.pdf (size about 4 megabytes) there is a few images and comments.
Currently it supports just PIC18F4620 (2620, 4610 and 2610 in theory), I’m planning to add support for another PIC MCUs, for another members of 18Fxxxx family it would be quite straightforward, for 18FxxJxx it would be somehow more complicated (another programming specifications). PIC16F probably will not be supported, as I’m lazy to redesign assembler and what is more, it seems that debugging various of those MCUs is much more diverse than for 18F. 16-bit PIC definitely will not be supported, as I don’t have a clue about debugging of them, as well as changes to assembler would be really dramatic (lots of opcodes and addressing modes).
Only single-supply ICSP is supported (using PGM), but it would be easy to change it into high-voltage ICSP, but I was lazy to include Vpp supply on board.
Well, and there comes point of this entire story.
My question is, whether there would be a demand for description of this gadget? There would be a hell lot of writing (description of debug mode, how to enter it, all diagrams, timings, how debug executive works, how I did it, how it could be done in other ways etc... I expect it to be sized like a MSEE final thesis), considering the fact this is not paid work :-) and I would like to know, whether it will not be just for nothing.
Another thing is that I will probably attend a local design contest, so I have to squeeze it into a small plastic case (and design PCB etc...), in order to look reasonably, so this will take me a lot of time and I better describe complete version.
There is only official debug specification for PIC16F87x from Microchip, so this would be a first attempt to give a more-less complete description of debug mode for PIC18 family.
I’m sorry about the fact that this specification (I keep in my head and in my source codes) is a result of reverse engineering. It seems that Microchip will better support lazy students desperately seeking for help why is their LED not blinking (usual cases: wrong oscillator, bad code etc...) rather than serious developers looking for information regarding “deeper“ aspects of PIC.
Now I’m expecting response, whether is there a demand for description of device, or just debug mode or nothing at all.
------------------------------
EDIT:
Note 1: seems like forum engine doesn't allow me to use word damned, I mean D.A.M.N.E.D. but it really captures reality, in this case, whether it is a "good" or "bad" word.
post edited by jarin - 2009/07/05 10:57:00