The JDM style programmer is great schematic and used by many peoples around the world, there is some issues with the schematic - it relays that the power for programming PIC is taken from the RS232 port, on some computers the RS232 driver is capable enough to ensure PIC programming, on some laptops and others the RS232 driver is not capable to source the current for PIC programming, this is why back in 2005 we made JDM design with external power supply. To our surprise IC-PROG still didn't manage to program some PICs even with external power supply and enough current. We took scope and diagnosed the problem: the software was violating the PIC programing specs. Here below is simple message exchange we had with the IC-PROG author. To the best of our knowledge the programming specs are still not changed in the newer software release.

----- Original Message ----- 
From: "Support OLIMEX Ltd."
Sent: Friday, September 09, 2005 1:58 PM
Subject: IC-PROG software improvement suggestion


 Hello Bonny,
 
 Let me introduce myself. My name is Tsvetan Usunov and I'm the owner of 
 Olimex Ltd in Bulgaria.
Our company designs and develop boards for different microcontrollers.
We have few PIC programmers which are based on JDM design and take power 
 from the Serial port.
Your IC-PROG software seems to be the most popular for JDM type of hardware 
and many of our customers use it.
Many customers of ours though have problems when program PICs with our 
 hardware and your software.
Sometimes the problems come from low power capability of the RS232 port, 
 however we made new modification with external power supply where the 
 voltage levels are perfect and while tested our programmer with your 
 software, some PICs  fail to program from time to time.
 
 We got digital oscilloscope and I think we found few problems:
 
1. you have IO Delay which could be set by the customer with different 
 values, but this affect only the SHIFT operation and you have standard 1ms 
 delay between sending two words when PIC is programmed, the 1 ms is very 
 small for PIC to perform the programming operation in the memory - it should 
 be from 1-10 mS for the different PICs, note that extending the SHIFT 
 operation helps somehow and in most of the cases PIC get programmed, but the 
 correct approach is to add delay between word shifts not only to delay the 
 shifting operation which in fact doesn't matter how fast is shifted.
Can you double check this issue? Perhaphs one additional PGM delay parameter 
 will solve all these cases of misprogrammed PICs?
 
 2. between the commands you send to PIC (not programming data) your delay is 
 also small - please add delay which may be the PGM delay described above.
 
 3. your clock is generated correctly, but your DATA shift suck :) if you 
 have two '1' high level in sequence your code seems that CLEARS the data 
 register before every port set operation which makes 1-0-1 sequence on the 
 port where the 0 is very short and probably due that you clear the port 
 before you set with the next shift value, in most of the cases this will not 
 cause problems, but on some weak RS232 ports and if the RS232 cable is long 
 enough the rise time 0-1 may be in such length that the PIC to read false 0 
 instead 1 at the clock rise edge. To avoid this please don't clear the port 
 before every next bit shifted
 
 I'm confident if the above three points are checked and fixed by you, your 
 software will rock!
 
 Let me know what do you think about this
 
 Best regards
Tsvetan

------------------------------------------
we got prompt reply:

From: "Bonny Gijzen"
To: "Support OLIMEX Ltd."
Sent: Friday, September 09, 2005 2:17 PM
Subject: Re: IC-PROG software improvement suggestion


Hi,
 
 
Let me say that I think your observations are correct.
However, I have a valid explanation to why IC-Prog behaves like this:
 
IC-Prog's support for JDM is 100% based on JDM's original sources (Jens
 Madsen).
He uses these extra transitions etc to charge/recharge capacitors on his
original JDM design.
 
I think because other JDM compatible designes are significally different, it
gives these problems.
 
Now, I think there is a nice way to solve this:
I am working on external programmer support.
This means each manufacturer can make his own DLL and can be loaded by
IC-Prog to drive the programmer.
 
Are you skilled enough to write a DLL  which drives your JDM Programmer ?
If so let me know, and I can pass you a Delph DLL skeleton project for
IC-Programmer driver.
 

Rgs Bonny,