PIC18 handheld toolchain, first try

This is just concept of such as device. In fact, it is not very "hanheld", but it serves as development board for development of such as device.


Its hardware consists of three main pieces.


Keyboard                    Main board                             Target device

Keyboard is a cellphone-like one (rotate it by 90 degrees clockwise) with a few added keys, like arrows (four yellow keys on right side), enter, escape to work with menu plus backspace and caps lock for editor and debugger. There is MCP23017 IO expender, driven by IIC bus. 16 keys is in a matrix 4x4 for port A, another 4 keys is tied directly to pins of port B, as well as two LED diodes,
















caps lock



























space, 1





















There is nothing special about target. Just PIC18F4620 with a few leds and caps.

Main board consists of dsPIC33FJ128GP802, IIC LCD display 96x64 pixels (with characters 6x8 pixel I got nice 8 lines of 16-char text), 45DB041 SPI FLASH (next to display, that one, which is so ugly soldered on DIP socket, in order to be socketable), MAX3232 interface and a few other components.


Software is based on four basic utilities - editor, assembler, burner and debugger - creating simple development toolchain.

This is basic screen with a small menu. You can choose from editing actual file, assembling the file, burning binary into flash, debugging the program. Last choice just examines device ID.

After pressing enter on this item (Edit) device enters Editor.

You see actual program listing stored in program buffer. You can move the cursor using arrows, edit it using enter (new line), backspace (self explanatory) and enter characters on cellphone-like keyboard. A bit painful writing, but can be. I decided to do this way because of small number of keys (good for small portable device).

On bottom line is line number (L:line number)

When you press Esc, you can see another one menu – what to do.

You can return to text, exit editor (leaving edited text in memory), save and load from/to FLASH, clear program buffer memory (ie. start a new program) and transmit/receive buffer to/from RS232. So you can send source file from computer and save it (clear-receive-save) or backup file (load-transmit) using normal RS232 terminal, available probably on all platforms (Win, Linux, Mac or even your old Atari or ZX-Spectrum could do the job).

When you editing is done, leave editor (Esc-Escape) back into basic menu.

Select Asm and press Enter. Current program will be assembled.

If there are any errors, assembler will complain – returning a type of error (missing operand, unknown opcode, argument out of range etc ...) also with line number. You can see the line number also in editor, so you can see where problem lies.

Assembler allows two directives - #def and #org. One is for defining constants and second one defines start address in program memory. Everything in a first row is considered as label, everything in other than first row is considered as opcode or directive.

When your program is assembled, you can proceed. Hit Enter and this returns you into basic menu, with binary image of assembled program in binary buffer and untouched listing of program in program buffer.

You can burn this binary image into flash of target device (Menu-FLASH).

As process continues, you can see messages, what is actually happening. When everything is OK, you will see Done on bottom line, or verify error otherwise.

Then is MCLR line released and target starts.

Building system to edit, assemble and flash binary into target was a minor stretch of brain compared to things hidden in fourth basic menu entry (Debug).

Thanks to help of John Peatman, along with long days and nights of reverse engineering and disassembling binaries, PicKit2 sources, documentation and lots of other sources I got across debug module on PIC18 and writing my own debug executives. But now, how it works in reality.

When you press enter on Debug item, FLASH is erased and written by binary file in binary buffer, along with debug executive and debug vector.

Then, target is reset and device waits to debugger executive to hook-up (when everything is OK, it’s in a blink of eye).

When debugger executive communication is established, a Ready message shows for a moment (500ms) and then debugger starts.

View selector:

WA – WAtch



BP - BreakPoint


Debug mode:

RN – RuN target

SS – Single Step

RS – ReSet

EX – EXit debugger


Source file



State of PC, W and S


View/Edit window





You can see two lines of source code (well, except of buffer with source file, buffer with binary file, there is also third buffer giving function between address in binary file and source file – this is necessary for source-level debugging) with a cursor (>) showing actual line, four choices of debugging mode, four choices for view window and state of PC, W-reg and S-reg in bottom line.

After pointing cursor (black brick) on RN and pressing enter, target runs from current PC location.


Now target runs with full speed, still under control of debugger.

It stops on user intervention – after pressing Enter key or after encountering a breakpoint, if any.

Hitting Enter brings you into debug program.

After a second...

As you can see, PC is changed, source file indicator is moved also into right location, along with other variables.

Setting cursor at SS allows you to do single steps. After hitting Enter is a single step exectued.


Note PC and W before and after – incf reg2 at 0x012, with W operand as default (to be changed into f default), with reg2 defined as 0x01, this increases value at address 0x01 containing 0x00 into W, resulting in value 0x01 in W and 0x014 in PC.

Hitting RS (Reset) brings expectable results.




Fourth line allows you to choose what is displayed on view window (fifth to seventh line). Default is Watch window (the same as selecting WA and hitting Enter). There are six variables, specified by full 12-bit address in hexadecimal notation.


You can select line and after pressing a Caps-lock key you can edit address and content of specified variable. This edit mode is indicated by e letter in a last row.


By using arrows up and down you can increase and decrease particular digit (address or content). Content of at given address is updated as address changes. You can also modify value at given address. After pressing Caps-lock letter e disappears and content (if changed) is written into specified address.

Pointing to RA and hitting Enter brings you into RAM view mode.

You can view content of 12-byte continuous block also change address of a first byte in block, in the same manner as in watch window. However you can’t alter content of this locations. For this purpose is there watch window.

Pointing to FL and hitting Enter brings you into FLASH view mode. You can do the same as with RAM viewer – alter address of block, but you can’t change FLASH content, so far


Pointing to BP shows you Breakpoint window.


By default, breakpoint is set to 0xFFFE, so it’s normally unreachable.

In bottom line you see address of actual breakpoint (A:XXXX) and address where pointer ($) points (S:XXXX). Set cursor (black brick) on BP cursor (dollar sign) and press Caps-lock. This brings you into edit mode, where you can edit breakpoint address, this is indicated by two dots on first row.

As you press up/down arrows, address of future breakpoint is decremented/incremented, and source lines (in view window, not in first two lines) are updated according to this. After pressing Enter, current address (S:XXXX) is taken as breakpoint address and it is written.

Dollar sign moves into this location. Then you can run target again (RN-Enter)

and it stops on location given by  this address – as expected from breakpoint.

In fact, the target stops at address increased by one word, as also there applies known breakpoint skidding – this is feature of debug module, not problem of debugger. ICD3 or PicKit3 has similar behaviour.

Exiting from debugger into basic menu is by EX-Enter

Jumps out.

Last item in basic menu (Test target) is just to show device ID.

Interesting is that this development chain works relatively fast, comparable to speed of PicKit2 on modern computer, the only "problem" with using as serious platform for bigger project is small keyboard and display, not assembler  / burner / debugger combo itself.

Schematics, source codes, etc...

I was asked to release sources and schematics of this device. Schematics are not done yet, but competent engineer can guess a lot of it from sources.
Pre-alpha sources can be downloaded here

Caution:  Use it at your own risk. Sources are probably uncomplete, buggy and lacks comments. However, it does what is supposed to do, at least for me. I really don't think you should replicate this device without actually really understanding how it works. If you don't understand it, try again to understand it before asking me. This is not suitable task for beginner.

Updated 20.2.2011

Back to P18debug