WinPic Frequently Asked
Programming does not work :
I tried this PIC programmer with my XYZ interface, which is supported, but
it doesn't work ?
First check the wiring of your programmer.
- If it is one of the TAIT style programmers, check if you selected the right
flavour (one of the four different types). Use the "interface test", switch
all control signals from PC to PIC on and off (without a PIC inserted), and
check the voltages. Check if the data signal (from PIC to PC) works properly,
with both high and low data bits. If your programmer uses tristate buffers
or relays, check the tristate control signals. Also check if the logic levels
are inverted or not.
- If you use the "JDM PIC-programmer 2" (the one where the PIC's ground is
on a negative voltage), disconnect "RB4" which is pin 10 for the 16F628 and
other 18-pin devices. This pin selects low-voltage-programming mode for some
modern PICs, which causes conflicts with the JDM- and other programmers.
The low-voltage programming algorithm is not implemented in WinPic anyway.
- If the problem occurrs with a dsPIC30Fxxxx or a PIC18Fxxxx, read this note
on "PGD and PGC filtering" !
If this doesn't help, check for problems with the interface settings (COM
port number, port access driver, etc). Read the next questions + answers
Programming and reading doesn't work, the 'interface test' seems to work,
but WinPic says "WARNING: Could not initialize the interface" ?
Check the wiring of your programmer. In 90 percent of all cases, bad wiring
was the cause, or a bad component (reversed collector- and emitter pin in
a bunch of 'bargain price' transistors).
Check if the state of 'Data In' on the Interface Test tab shows the
correct logic state of the serial ; when the PICs serial output is 5 Volts
"Data In" must read "1" (logic), near 0 VOLTS it must show "0". If not, check
the wiring again. If you use a programmer on the parallel port (LPT), see
Programming fails, and WinPic says "WARNING: Windows fooled around with the
LPT port bits". What does that mean ?
This message means, that -for some strange reason- windows has reprogrammed
one of the control registers of the serious ports. WinPic checks from time
to time, if a value it has written into a certain register is still in there.
If the register value seems to have changed by mysterious ways, it shows
the warning mentioned above. The reason is usually some kind of driver which
lurks in the background (of the windows driver system), and watches the parallel
port. If "something" happens on the port, it tries to talk to a printer,
a scanner, or whatever is usually connected to that port. So what to do:
make sure no printer driver, or scanner driver, etc, has occupied this
port (though WinPic usually works even though a printer driver occupies the
port !). I got a report from a user of Windows 2003 that on his system, the
culprit was a scanner driver, and after shutting that thing down the strange
error messages from WinPic disappeared.
Under certain versions of Windows XP, this problem can also be caused by
the Plug-and-Pray-System, which periodically polls the parallel port (actively)
to detect new hardware. You can disable this 'feature' as described
I tried WinPic under Win98, where it worked, but it doesn't seem to work
under Win2k, or Win XP !
Most likely, another problem with the direct port access driver. WinPic accesses
the control registers of the serial (or parallel) interface, which is a "no-no"
these days (long after DOS..). Try to run the computer with an administrator
account, or try to register the SMPORT- or PortTalk driver so WinXP will
load it as a registered service when booting.
Sometimes the problem seems to be related with other programs running
simultaneously, so do not let any other program run while programming
PICs. Especially not programs which try to use the port where your PIC programmer
is connected (like scanner drivers, printer status monitor, etc).
Other programs which also use a "port access driver" (like Motherboard Monitor,
etc etc) can cause conflicts with the port access driver, and you may get
strange error messages from the system. In that case, either SMPORT or PortTalk
may work. If none of them works, try to shutdown the other program (which
often requires reboot), and try again.
If it still doesn't work, use a programmer for the serial port, and a
"good"(*) USB <-> RS-232 converter
on a free COM port number (1..16), which will exclusively used by WinPic.
Programming a PIC16F84 works, but programming a 16F628 does not work with
my programmer - why ?
There is a major difference in the programming specifications. Most newer
devices require a very fast rise on Vpp and / or Vpp (less than 50 microseconds
between them) which is impossible with some of the "extremely simple" programmers
I have seen on the web. The problem is, if the PIC starts executing its code
because Vdd (the supply voltage) is present, but Vpp (the programming voltage)
is not raised to say 12 Volts fast enough. So the program counter will not
be zero when entering programming mode, and programming will fail for this
reason. Get or borrow a two-channel oscilloscope and measure these voltages.
If there is a slowly rising edge on the Vpp pin, throw those large electrolyte
caps out to make the rise time faster. Or, invest a few pennies / cents for
a few transistors and build a better interface.
There is a workaround for this problem when using the JDM programmer: WinPic
sets all control lines HIGH for about 500ms, which should discharge all
capacitors, before applying the Vpp voltage. I tried this successfully with
a PIC12F675, where the MCLR-input had been disabled previously, and had no
problem when trying to overwrite the chip. If this doesn't work with your
JDM programmer, let me know, maybe making the 500ms discharge interval even
longer helps. About the JDM programmer and oscilloscopes: DO NOT CONNECT
THE OSCILLOSCOPE TO THE PIC'S GROUND - the scope's ground will most likely
be connected to the PC's ground, which causes a short circuit for the JDM
programmer's tricky supply voltage !
Programming my PIC16Fxxx device worked ok for the very first time, but then
I cannot program an already programmed device.
Similar reason as above - too slow rise time on Vpp. The situation gets worse
if the PIC is already programmed, because the MCLR function ("reset pin")
of a programmed device may be disabled via software (16F88 and many others).
So the PIC will even start running the code when the Vpp/MCLR voltage is
almost zero. Then, in one of the first instructions, it may reprogram the
TRIS registers to turn the pins which we need for serial programming into
Cure: Same as above.
Programming with my simple COM-port interface works on one machine, but not
on another machine ?!
The output voltage from the serial port may be too low (which is often the
case on newer machines), or the port driver is too weak to let the Vpp voltage
rise fast enough. Use a different PC, or try to boost the Vpp voltage.
The problem may also be related with capactive coupling from data ("PGD")
to clock-line ("PGC") in the interface cable. See the note on
"PGD and PGC filtering". It may
save you from a lot of headaches (for me, it did, after discovering it in
the Microchip forum).
My old programing interface did work with another (old) programming software,
but not with WinPic - Why ?
The delay loops in WinPic are just as long as required, but not much longer
(*), to make the programming cycle as fast as possible. If you use a long
cable on the parallel port, the clock- and data pulse may suffer too much
from the large cable capacity. Try a shorter cable, and -if possible- watch
the waveforms with an oscilloscope. Also take care that the Vdd buffer capacitor
is small enough to let the supply voltage rise to 5 volts before programming
starts. 10 Microfarads is too large, and does not really help if the supply
is too weak. With these kinds of interface, you will get into trouble when
programming one of the newer PICs like the PIC16F88, or one of the -A
(*) - except for the JDM-programmer, which needs longer pauses to avoid too
much load current for the weak supply. Do NOT reduce the 100uF and 22uF
capacitors there, it should work (I checked WinPic+JDM with a 16C84, 16F84,
16F628, 12F675, 16F876A, dsPIC30F2010 ; all ok).
Questing regarding certain device types :
There is a new super-duper PIC device named PICxxFxx(x) now. Can you add
support for it ?
Maybe you can do it yourself by adding a new section to the file DEVICES.INI
. See manual. If not, please don't expect me to do so immediately. I am doing
all this in my rare spare time, and cannot buy samples for every new chip,
just to have it laying in my junkbox thereafter. Chances are good that the
new 16F devices (with 14 bit code memory) can be supported without having
to modify WinPic itself. The support for PIC18Fxxxx and dsPIC30Fxxxx is almost
'universal', all which may be missing is the a small new section in DEVICES.INI
Programming PIC16Fxxx works, but PIC10F20x does not.
Try running WinPic on a faster machine. If using WinXP, use administrator
priviledges (causes less problems with the SMPORT driver). There are some
tough timing requirements for this family of PICs which did not exist for
Furthermore, the PIC10F20x requires a maximum rise time for the MCLR/Vpp
signal (from zero to 13 volts) of 1 microsecond - that's tough for certain
interfaces ! So some "simple" interfaces may not be able to program PIC10F20x
devices. I tried the SM6LKM parallel port interface, and "JDM2" + "COM84"
for the serial port. All of them worked fine with a PIC10F206 .
Why are the dsPIC programming routines so terribly slow ?
Because up to now, WinPic only uses the STDP protocol for programming, which
doesn't rely on the presence of the "programming executive" (kind of bootloader).
For more info, read the dsPIC30F Flash Programming Specification (DS70102,
available on the Microchip website). To speed up dsPIC programming (and PIC18F
too), try the PortTalk access instead of the SMPORT driver. Some details
are here .
There is another brand-new device called PIC18Fxxxx
now. Can you add support for it ?
Most likely, yes. Martin van der Werff (-thank you Martin ! -) has added
support for most (if not all) PIC18F devices. You may need to add an entry
in the DEVICES.INI file if your chip is not in it. Supported "older" PIC18F
PIC18F242, PIC18F248, PIC18F252, PIC18F258, PIC18F442, PIC18F448, PIC18F452,
A few newer PIC18F devices (PIC18F2XX0/2XX5/4XX0/4XX5):
PIC18F2410, PIC18F4410, PIC18F2420, PIC18F4420, PIC18F2455, PIC18F4455,
PIC18F2480, PIC18F4480, PIC18F2510, PIC18F4510, PIC18F2515, PIC18F4515,
PIC18F2520, PIC18F4520, PIC18F2525, PIC18F4525, PIC18F2550, PIC18F4550,
PIC18F2580, PIC18F4580, PIC18F2585, PIC18F4585, PIC18F2610, PIC18F4610,
PIC18F2620, PIC18F4620, PIC18F2680, PIC18F4680,
These PIC18F routines were tested using the JDM2 programmer on PIC18LF2550,
PIC18LF4550, PIC18LF4455, and PIC18LF458. If that "new" PIC18F device is
not one of the above, be sure to define the size of the code memory write
buffer (8, 32, or 64 byte), so WinPic selects the correct programming algorithm
for these devices.
Erasing my PIC18F2xxx / PIC18F4xxx fails. In an older version, it worked.
Something screwed up in WinPic ?
Answer: No, something screwed up in Microchip's "Flash Memory Programming
They changed the command pattern for "Bulk Erase", somewhere on the way between
DS39622A and DS39622J.
Because it was unclear if "old" chips can also be erased with the "new" command
sequence, WinPic still contains the old erase algorithm. To define which
one to use, open the file DEVICES.INI, scroll to the section for the PIC
you use, and modify this line:
EraseAlgo=PIC18F (this lets WinPic use the "new" bulk erase command,
as specified in DS39622J)
or EraseAlgo=PIC18F_OLD (this selects the "old" bulk erase command,
as specified in DS39622B).
More details about the "new" and "old" PIC18F chip erase commands is
here (in the description
Questing regarding program operation
After 'Erase', the configuration word is not blank. Is this an error ?
No, someone else would say "It's a feature but not a bug" --- well seriously,
WinPic has to select one of two possible erase algorithms depending on the
code and/or data protection bits. In the programming specs for newer PICs
Microchip calls this "Chip Erase" or "Bulk Erase". If the chip *was* protected,
the config word is erased, otherwise not. For other devices, the config word
is *always* erased.
How do I get back the BG calibration bits in the config word ?
Usually, WinPic will read these bits from the config word (where applicable)
before erasing, and set them back to the original state when programming
the config word. So you don't have to care under normal conditions.
However, if you goofed around a bit too much, and the bandgap calibration
bits got lost, set the checkmark "no special treatment for BG calib" under
"Programmer options". After this, you can modify these bits by entering the
config word in hexadecimal form on the "Device, Config" tab. It's a good
advice to scratch the value of the BG calib bits into the plastic case of
the PIC before starting to play (the same is true for the oscillator calibration
word, see below).
Why is the last location in the code memory window painted in a different
colour after reading a PIC ?
For certain devices, this is the value which should be written into the
Oscillator Calibration Word - actually it is a RETLW instruction which you
should call from your initialisation routine. This can be used to (kind of)
"calibrate" the frequency of the built-in 4 MHz RC oscillator in some devices.
It is not required for crystal oscillators, but may be a good idea to preserve
this value (I used to scratch it into the plastic housing of my first PIC12F675
samples). After reading, WinPic shows the Osc Calib word along with the BG
calibration bits on the "Device, Config" tab.
In an Erase-Program cycle WinPic automatically saves and re-installs these
data, so you normally don't have to bother. If you try to "calibrate" the
PIC yourself, and want to write your own osc calib word to the end of the
data memory, set the checkmark "no special treatment for OSCCAL" in the
Programmer options box.
Why does WinPic suddenly lock up the entire PC when my pic programmer is
powered up ?
Sounds like an issue with the SMPORT driver. This driver is required to enable
direct access to the I/O ports which control the serial or parallel port.
Make sure SMPORT.SYS and SMPORT.VXD are located in the same directory as
WinPic, or in the windoze system directory. Under Win NT (or similar) this
may not work properly if you do not have an administrator account. Search
the web for "SMPORT by Alexander Weitzman" for details, and -probably- a
more recent version of SMPORT. Or try the PortTalk driver (which can optionally
be used by WinPic since November 2005, more on this
Warum ist die ganze Beschreibung nur in englischer Sprache ? (Why no german
If you are seriously planning a carrer as an electronic guru, or similar,
be prepared to learn English - at least a bit. Sorry my time is too short
to translate all this into my native language, which is German. Keeping the
english and german version actually would take MORE THAN twice the time,
keeping everything 'synchronous' - time better spent in improving the program
or supporting new devices. At least, the recent WinPic versions can be switched
to German language for the user interface, and maybe to other languages too
(anyone is invited to translate the string table files; it is plain textfile
- more info is in the readme file).
I use a dsPIC30F6010 (or similar chip with large code memory), and find reading
or writing it is utterly slow. How can I make
WinPic faster ?
Try switching from the SMPORT access driver to the PortTalk driver (on the
Options tab), and check if FastPort
works on your machine. You must exit WinPic and start it again so it can
load the new driver. Under WinXP, you may need an admin account to do this.
Next, switch to the Interface tab. Since November 2005, there are two new
edit controls ("extra delay..") where you can specify the delay times your
interface needs for every serial clock pulse, and before reading the state
of the data line. Tweak these values for the minimum values (the point, where
verify gives no errors, then add one more microsecond for safety).
If you prefer to run WinPic without admin privileges, it gets a bit more
tricky. You will need to install the PortTalk driver manually, so WinXP will
load and start it automatically when the PC is booted. How to achieve this
under WinXP is explained here.
Can you send me an etched PCB for your PIC programmer ?
Sorry, no. Time is too short and I don't want to make money with electronics
in my spare time.
Can you send me a programmed PIC with the firmware XYZ.HEX ?
No, same reason as above.
Can I send you my PIC programming interface or the PIC which was blown with
your software for repair ?
No, please... Look for 'local advice' if you need. Many users have built
their own board successfully, and so you should. Apart from that, did you
read the disclaimer on my website before downloading and using WinPic ? If
not, it's also in the WinPic manual ;-)
Where can I buy PICs in my country ?
In Europe, Digi-Key, Farnell and RS Components do sell them (amongst
others). In Germany, Reichelt Elektronik does, with fair prices and fast
delivery, though they may not have the newest devices in stock. Beware, the
prices for some PICs in single quantities differ greatly
between the named distributors ! The price for a single PIC12F675-I/P was
over 12 Euros (in early 2004) - ridiculous, when another distributor (find
out which!) sold the same part for 2.10 Euros for a single unit. So check
different sources before ordering !
Why did the size of WinPic.exe grow from 257 kByte to over 740 kByte in early
Because I decided to link all required DLL's statically into the program,
so you don't have to download Borland's VCL40 as a separate file.
(*) A "good" USB <-> RS-232
converter produces an output voltage swing of at least +/- 10 Volts, has
all handshake lines on the RS-232 side implemented, and has a good driver
software which really supports all these handshake lines through the Windows
API functions for the serial port. Beware, some interfaces / drivers don't.
If your USB <-> RS-232 has an FTDI chip built inside, it will be a
last modified: 2007-01-25 (ISO-date-format, which is YYYY-MM-DD)
--... ...-- ...-.-