Hi guys, jaromir from
http://jaromir.xf.cz/ here. I'm reliving this old thread to put all the information on single place - for the (perhaps a bit unlikely case) someone would be interested in the topic and add a few more details than I wrote in here
http://jaromir.xf.cz/hdeb/goals/goals.htmlLet's start with quick Q and A:
Q: Why on earth would you do your own debugger, when official tools work just fine?
A: Because I can. And because it's fun, discovering something new is amusing. Yes, it is completely pointless, but that's the point of hobby work. I have to do logical and needed things at work, all the time. For my hobby time I reserve my spare time to do all kinds of useless crap, it it makes me fun. Did I tell you I made my own cell phone, digital camera or GPS receiver? Oh my, such as waste of time!
The debugger project goes all the way back to year 2010 or so. I thought like it could be just fine to have small handheld device, being able to program another PIC with specific FLASH image. Well, that's somehow boring, so I thought of adding binary editor, able to change the image. With opcode list at hand I could enter and load programs of target PIC in machine code - the same way as you did it in 70's/80's in KIM-1 or similar entry-level computer kits. Being born in mid 80's - I was too late to experience it in my youth. Consequently, my thoughts lead me to ASCII editor to enter programs in assembly language, on board assembler could translate it to machine code. Now that starts to look like complete toolchain. I built such as device, sporting PIC18F2620 as brain of it and another PIC18F2620 as target device. User interface was 4x4 (plus few function keys) keyboard, with layout as on old cell phones and 98x64 graphical LCD, giving me 16x8 characters of 5x7 font. The whole thing fit into a few kilobytes of FLASH and worked just fine, but there was something missing. Actually, two things: high level compiler and debugger. Unfortunately, HLL compiler, like C or Pascal was completely out of my reach - I had no idea where to start. Assembler is fairly easy, just chasing strings and spitting out binary values; but compiler was completely different story. So I decided to make some debugger.
It was not easy thing to do, as Microchip doesn't make any documents public. The only thing officially available is debug register description of PIC16F877 - the rest of it had to be guessed, resulting in rudimentary description as here
http://jaromir.xf.cz/hdeb/bdm/bdm.htmlI implemented the debugger into PIC18F2620, but it started to show it's weak points, like too little RAM and somehow 8-bit architecture. So I took dsPIC33FJ128GP802, the biggest RAM PIC MCU in DIP package, ported all software components (editor, assembler, programmer, semi-finished debugger) and finished it into single monolithic package. The result is to be seen here
http://jaromir.xf.cz/hdeb/desc/hdeb_desc.htmlAt the time (winter 2011/2012) Designspark started a contest, aiming at then new chipkit32 board with PIC32 MCU. So, I ported the debugger again, to PIC32, result of it was PIC Programmer, fourth revision - PP04.
PP04 included a lot of redesigned software. The menu-driven interface working above linear memory space was thrown out and I implemented command-line driven "operational system" working above FAT32 filesystem - I must admit I was slightly inspired by GNU bash, though my CLI is far far from being as powerful. You can now use commands like ls (ls *.as to list all files with "as" extension), cp, md or rd to operate with files and directories. You have simple ED editor to edit, AS to assemble files, PG to program and DE to debug the target PIC18 formware. To have more fun, I added simple BASIC and BF interpreters.
More info about PP04 is to be found here
https://hackaday.io/project/1757-pp04-camel-computer, notice also the download section with complete documentation and C source files. Beware though, my coding style is far from perfect and at the time was even worse. Comments are rare, organization is messy and code not very self-documenting, You've been warned.
The original Designspark contest disappeared from their website, along with the documents, so I made the public display at hackaday.io site. If there is anybody else to make mirror of those documents/projects, feel free to do so, just let me know.
The debugger itself is no rocket science you understand how it works. Though the understanding took a lot of time and effort, nights spent with oscilloscope and logic analyser to chase bugs in debug executive or debugger itself.
First of all, it loads user program as usual with one difference - all code protect bits are disabled and DEBUG bit in configuration word is programmed to 0 = enabled. Plus, debug executive has to be added, but I'll get there later. From now, the device enters debug mode every time when there is transition 1->0 on RB6 pin, reset happens (those two can be induced from debugger at any time) or breakpoint is hit/single step is done (those two are possbile after previous debugger action). The actual debug mode is nothing but kind of "interrupt" with vector at 0x200028 and special program, called debug executive has to treat all the debug actions and bitbanging serial communication via RB6/RB7 pins to debugger probe. More details are here
http://jaromir.xf.cz/hdeb/bdm/bdm.htmlI wrote the debug executive programs in assembly language, as it has to be very compact and every byte matters here.
My approach is somehow different from what Joseph Watson did - he debugged program entered by bootloader, so you have to program the bootloader first. I considered this one too, but it slightly limits its usability. I wanted "real" debugger, doing all required actions even with unprogrammed "virgin" PICs and via only two pins RP6/RB7. I love to make things harder
Anyway, Joe's work is great and I'm glad not being the only one fiddling with undocumented features of PIC18.