WISP: Wouter's In - System flash PIC Programmer

Fonte: Wouter van Ooijen

This design is shown for 'historic' reasons only.
Wisp628 is an up-to-date Wisp-like programmer, based on the 16f628.

According to Marten Toonder, a dutch author of fairy-tale-like cartoon stories, a wisp is a special kind of wasp. The sting of a wisp makes the unfortunate receiver tell only the truth while the pain lasts.


highlights

WISP's highlights are: in-system programmer;
  • it supports a rapid cycle of coding/programming/running;
  • it is a production programmer;
  • power can either be taken from the target or delivered to the target;
  • its uses the simple serial interface;
  • it offsers a serial bypass to the target.
  • WISP is an in-system (also called in-circuit) programmer, so WISP is connected directly to a system which contains the 16f84 which is to be programmed. The target circuit must be compatible with the WISP programmer. There is no need to remove the 16f84 from the target circuit, it could even be soldered permanently. A simple 4 or 5 wire connection to the target is sufficient.

    WISP supports a rapid development cycle: without even touching the target hardware you can program the target, reset and start it, and communicate with it.

    WISP is a production programmer because it can set the voltage at which it verifies the correct programming. The distinction between a production programmer and a prototype programmer is that a production programmer must be able to verify the correct programming (check the content of the program memory) at the extremes of the Vcc which will be used in the application. This is more relevant for the EPROM-based PIC than for the EEPROM/FLASH-based PICs that WISP can program.

    To use WISP as a production programmer, it must be calibrated. This requires only the WISP tool, a multimeter and some patience.

    WISP can either take its power from the target circuit, in which case a stable 5V @ 100mA must be available from the target PICs pins, or it can deliver power to the target (via the same pins). In the latter case a wall-mounted transformer must be plugged into the WISP. In both cases the voltage which is needed to enable programming on the 16f84 (12-14V) is created from the 5V by a charge pump. When the target delivers the power, WISP can not control the voltage, hence in this case it can not be used as a production programmer.

    WISP uses a

    serial interface with a simple protocol. The timing of the communication does not affect the programming process.

    WISP provides a serial passthrough which is usefull when you want to communicate with your target system. The same serial line which is connected to WISP can be passed on to the target system's lines RB6 + RB7. The passthrough is implemented in software, so it is limited to baudrates of 19k2 and lower.



    hardware

    The WISP hardware consists of

    WBus serial 'interface' (upper left part: CON2-3, R1-R2 and D1) A full bridge rectifies whatever is supplied on the power connector. The result is shared via WBus (CON2-3) pin 1. C1 must be able to withstand 40V (20V AC on the power plug, plus some margin). Without intervention from the PIC (RB4-RB7 are inputs) R13-R15 cause a 5V voltage at IC1 pin 2. Various other voltages can be created by assigning the pins RB4-RB7 to input, high or low (4^3 = 81 combinations). The relation between the PIC RB4-RB7 setting and the resulting voltage is too complex to predict, even with 1% resistors, so the PIC's EEPROM is used to store the RB4-RB7 settings used for the various usefull voltages (4.0V - 6.0V is steps of 0.1V).

    While programminging the charge pump is exercised at around 100KHz by PIC pins RB2 and RB3. It produces a Vpp of 3 times Vdd minus 3 diode drops. While sending or receiving a character the PIC firmware does not operate the charge pump. Capacitor C6 bridges these periods (one character at 19k2 = 500uS).

    The PIC uses a standard 10MHz Xtal with accompanying capacitors. The 'reset circuit' R7 is simple but compatible with the WISP requirements, so a WISP can program the PIC in another WISP. The LED D6 can be switched on and off by the PIC to give some feedback to the user.

    The target connector CON4 provides the ground and the three programming lines (to be connected to RA3, RA4 and MCLR). The resistors offer some protection against wrong connections. PIC pin RA4 (open drain) is used to control the target's MCLR line. R6 makes it possible to load C6, pull RA4 low to reset the target, and then let RA4 float to get the target in programming mode using the remaining charge in C6. To get the target in run mode RA4 is pulled down long enough to discharge C6 (to Vdd minus three diode drops), and then RA4 is floated. The reset circuit in the target should then keep the MCLR pin high enough.

    The target connector also provides a Vdd connection. This can be used to power the target from WISP or to power WISP from the target.

    This picture shows the first WISP on a PCB. It is an older version which could not control the target's Vcc (7805 instead of LM317). The connections to the left ar the WBus connections (in and out). To the right are the target connector and the power connector (not connected here: the target delivers the power). Note that the DB5 and DB9 connectors are of the cheapest variety. Only one row of these connectors is used, so they can be soldered directly to the copper side of the PCB.

    I made the WISP schematic and PCB using the IVEX schematics and PCB software. I'm not sure I can recommend their software (it is very buggy), but in the end I did succeed and they offer a free version up to 100 pins. If you are going to use it, save your design very often!

    A suitable connection between WISP and the target PIC can be made via a dedicated connector on the target circuit (for instance a berg header or an 8-pin DIL socket), or directly to the chip using a DIL test clip. The cable from WISP to the target should be not be too long. Half a meter worked fine for me.

    This picture shows a PIC on a breadboard with the test clip on it. I could not get an 18-pin clip, so I used a 16-pin clip instead.

    WISP must be able to drive the targets MCLR pin via a relatively high impedance (5k), up to the 14V programming voltage. This rules out direct use of a capacitor to time the reset. Some WISP compatible reset circuits are:

    • just a 33k to Vdd (might not work when the Vdd switches on slowly)
    • an RC plus diode (as proposed in Microchip's in-circuit programming guide)

    Three notes about the schematic:

    • The pin number of the DB9 connectors is WRONG: 5 should be 1, 4 should be unused etc. Sorry, I don't have the time right now to correct this (thanks Rob).
    • With some computers a lower value of R2 is reqiured to get a good low level on the RS232 to the computer. A value of 560 ohm is reported to work well (thanks Angelos).
    • The power distribution has fried my main board, so it might not be a good idea and I removed it from WBus. Leave out the connection between the positive side of C1 and the D9 connectors (on the PCB it is a wire, not a PCB trace).



    firmware

    The firmware (the software running on the 16f84) for WISP is available as hex file. The same file can be used for either a 16c84, a 16f84 or a 16f84A, each with a 10MHz Xtal. The sources are also available.


    protocol

    The WISP firmware supports a simple ASCII protocol, which adheres to the WBus definition. This makes it possible to connect a number of WISPs or other devices which adhere to this protocol to the same serial line.

    Some knowledge of the WISP protocol might be needed when you want to port the existing WISP tool, create a new one, or simply want to test your WISP hardware using a terminal emulator. For a simple PC-to-WISP connection this requires only a 9-pin serial extension cable. Some WBus key features are:

    • uses only GND, RxD, TxD;
    • the timing of the programming process does not depend on the timing of the serial communication;
    • the voltage levels can be low because the serial lines do not deliver power to WISP (actually the levels provided by WISP are way below RS-232 spec, but this is usually not a problem).
    This is great for laptops, non-dos systems etc. Due to the below-spec voltages WISP provides on the RS-232 lines it might be incompatible with some rs232 ports.



    software

    The WISP tool is a command-line program which can be used to control the WISP hardware. It is available as source or as executable for DOS/Windows. It is written in TurboPascal.

    The XWisp tool is both a command-line and windows interface program which can also be used to control the WISP hardware. It is available as Python source. It will run on all kinds of Windows, but also on Linux and most other operation systems.

    The WISP protocol is simple, so it should be possible to write your own host software. If you do so consider making it freely available and drop me an email so I can add a link to this page.


    downloading

    Besides the html files the following is available for downloading: hex file
  • the WISP firmware sources
  • the WISP schematic in IVEX format
  • a WISP PCB layout in IVEX format
  • comp.ps and solder.ps, the component and solder layers of the PCB in postscript format
  • NOTES on the PCB: the component side shows the diode bridge and the LED in a wrong orientation. The bridge + should be to the elco + and the round side of the LED should be towards the D15 connector. The LM317 is also shown wrong: the metal side should be towards the edge of the PCB, not towards the centre.



    targets

    With suitable host PC software a WISP should be able to program all eeprom/flash based PICs. WISP can not be used to program OTP PICs because on those chips the 12-14V is used to power (not just enable) the programming, so much more current is needed that WISp can provide.

    The currently supported target chips are:

    • 16c84, 16f84, 16f84a
    • 16f627, 16f628
    • 16f870, 16f871, 16f872, 16f873, 16f874, 16f876, 16f877
    To program a chip that has LVP capability (16f62x and 16f87x) it might be needed to tie the LVP pin (RB3 on 16f87x, RB4 on 16f62x) low (using for instance a 10k resistor).


    rationale

    There are plenty commercial and free 16f84 programmers available, so why did I create yet another one? One answer is 'just for the fun', the other is that I wanted a programmer which fits my special needs and I did not want to buy a commercial product.

    I have succesfully used my own variant of the RS232-powered programmer for some time (three cheers for the abundance of free 16f84 hardware designs and support software!) but I grew tired of the (relatively) long development cycle. For me the steps were:

    • on my Pentium2 machine assemble the source (using MPASM) and copy the hex file to a floppy;
    • on my 486 machine close the wterm used in the previous cycle;
    • start a DOS box with com84 and pip02;
    • read the hex file from the floppy into pip02;
    • remove the Xtal from the breadboard;
    • connect the 486's rs232 line to the programming interface;
    • program the 16f84 from pip02;
    • exit pip02, remove com84 and close the DOS box
    • connect the 486's rs232 line to the PIC serial lines;
    • put the Xtal back in the target circuit;
    • launch wterm to identify the next bug.

    The reasons for this elaborate development cycle are:

    • I can not program directly from the P2 machine, because pip02/com84 won't work (not even when I boot from a DOS flop).
    • I don't want to run MPASM on the 486 because it is way too slow. (I guess that's partially my fault: I use an awfull lot of macro's.)
    • I have only one free serial line on the 486.
    • I can't connect the 486 and the P2 to the PIC circuit at the same time (ground loops or something like that).
    • The programming does not work while the Xtal is in place. I guess I that's because I use a separate power supply instead of deriving the power from the rs232 lines like I should. But I don't want to take the 16f84 out each time I program it, and the serial line can not power my whole target circuit.
    So I decided to make my own programmer to shorten the development cycle. I had just bought a bunch of 16c84 chips so I used one of those and put the features in software (on the 16c84 and on the host machine) instead of using pure hardware which would possibly have been cheaper but certainly less flexible. I'm a software professional and only a hardware amateur and my scope (second hand HP, all tubes and germanium, 40 kilo!) had just died, so I felt more comfortable debugging software than hunting hardware bugs.

    WISP has speeded up my development cycle tremendously: download-and-run takes about 10 seconds. The next step is to replace the slow and primitive MPLAB assembler by something better and faster, but that is a different project.