WinPic  Frequently Asked Questions

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 next FAQ.
  
• 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 here .
  
• 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 "digital outputs".
  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 devices.
  (*) - 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 other devices.
  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 devices are:
  PIC18F242, PIC18F248, PIC18F252, PIC18F258, PIC18F442, PIC18F448, PIC18F452, PIC18F458.
  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,
  PIC18F8490 .
  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 Specification" !
  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 of DEVICES.INI).
  

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 here).
  
  
• Warum ist die ganze Beschreibung nur in englischer Sprache ? (Why no german documentation ?)
  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).
  

Miscellaneous

• 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 2004 ?
  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 good one.

--... ...-- ...-.-