Problems with JDM2-type programmer and WxPic

Problems or tips related to the use of WxPic

Problems with JDM2-type programmer and WxPic

Postby Wook » 20, 2010 Feb Sat 3:59 am

Computer is a Compaq Presario w/1gb RAM, 2.5GHz Celeron, running WinXP Pro SP2.

I built an alternate version of Feng3's MultiPic 5.2 programmer, which was derived from the JDM2.
Documentation for the MultiPic is on this page:
http://feng3.cool.ne.jp/en/pg5v2.html

Problems:
1) The first three bytes of flash memory don't program properly.
2) Erase is unreliable (almost never works), which I believe is directly related to 1)

There is a noticeable drop in Vpp/MCLR right as the programming or erase sequence is starting (the LED becomes quite dim); which is a big reason why the erase function is not working properly, and likely the reason the first few bytes don't get programmed correctly.
The first four bytes of the program should be:
000000: 01E1 0803 0183 00A9
But are almost always:
000000: 3FFF 3FFF 0000 00A9

WinPic, compiled 8/29/2009, exhibits the same symptoms with this programmer.

The odd thing is that IC-prog v1.06B by Bonny Gijgen and WinPic800 by Sisco Benach Font work just fine on the target uC a PIC12F675 with the default settings. They read, program, verify and erase it with no problems encountered.

Yes, I know, I know... since it's a JDM2-type programmer, the MCLR can't come up to 12v before Vcc is up. Well, it does - it's close to the target voltage before Vcc gets above 2.5v.
Schematic link: http://feng3.cool.ne.jp/pgm5v2/sch528.gif

I've modified the programmer by adding 100 Ohm resistors in the clock and data lines, and also added 33pF caps at the end of the traces to act as a low-pass filter. This hasn't seemed to have helped of course; it's because the Vpp/MCLR voltage is dropping too low. The Vdd also gets too low; nominal for the erase function is 5v, with a range of 4.5v to 5.5v.

The only thing I can think of is that the WxPic program gets really busy doing other things right before the initial programming/erase commands, and "forgets" that it needs to keep the COM port lines in a state that will keep the uC ready to program/erase.
Wook
 
Posts: 7
Joined: 18, 2010 Feb Thu 6:24 pm

Re: Problems with JDM2-type programmer and WxPic

Postby Wook » 20, 2010 Feb Sat 5:25 am

After some more thinking and experimenting, I observed that WinPic800 and IC-Prog kept Vdd at 5v all of the time, where WinPic and WxPic would drop Vdd to 0v.

I replaced C1 and C2 (originally 100uF) with 22uF caps to decrease their initial charge time, and then did some experimenting with timing parameters.

Data line delay: 6uS
Clock pulse lenthening: 4uS
...seem to be working well; I have read/erased/reprogrammed/verified this same PIC12F675 now a half-dozen times with no errors.

After yet more testing, I started getting errors again, so increased the delays:
Data line delay: 8uS
Clock pulse lenthening: 5uS
...and the problems seemed to go away for the moment.

I'd previously tried these options with the larger caps, but hadn't made good progress. I'm rather encouraged by these latest results.

While I managed to make the fix using replacement components after some troubleshooting and general "tweaking", this might be considerably more difficult for someone that has minimal access to test equipment and/or the ability to use it.

Please consider adding provisions for an extra delay after turning on Vdd/Vpp/MCLR to support the MultiPic 5.2 in it's existing configuration. I will suggest to Feng3 that the 100uF caps should be reduced for better results with WxPic.
Wook
 
Posts: 7
Joined: 18, 2010 Feb Thu 6:24 pm

Re: Problems with JDM2-type programmer and WxPic

Postby admin » 20, 2010 Feb Sat 4:44 pm

Hello,

I don't understand how Feng3's schema can work with a 12F629 or 12F675 that requires VPP to be reached before VDD is on. R4.C3 time (10µS) is far shorter than the time of C1 or C2 with the line resistance (at least 100mS) so it cannot delay significantly VDD compared to the slow raising of VPP.

If you succeed to program your PIC12F629 I suppose I there is a trick that allows VDD to stay low. I don't understand the role of R5 or why R3 is so low and I am concerned by the reverse voltage on Q3 base when VPP is on. But the trick does not seem to be around there, because I just see a transistor that prevents VDD to go significantly above VPP, but nothing that brings VDD below VPP.

In fact I believe that this schema can only rely on the incapacity for the serial line to pull more current from low RTS than it can push on high TxD, even when the average voltage of those inputs is higher than serial port ground. I am not sure that this is written in RS232 spec and that all port implementations will work with it. But if it works with yours that's fine.

Now to solve the issue about the raising time for VPP and VDD, I checked in WxPic and I saw, specifically for the JDM2 interface, that the delay after switch on is hard-coded and its value is 260mS. So to try to solve your blocking issue (and to know if it's actually the issue) I have modified this value to set 500mS and I have regenerated the executable. You can get this patch here. Uncompress with 7-Zip and replace WxPic.exe in your WxPic installation directory with the new executable. There is no other change from V1.2.1 in this binary (except the auto-generated version identification).
admin
Site Admin
 
Posts: 153
Joined: 12, 2009 Jul Sun 7:20 pm

Re: Problems with JDM2-type programmer and WxPic

Postby Wook » 20, 2010 Feb Sat 6:00 pm

admin wrote:Hello,

I don't understand how Feng3's schema can work with a 12F629 or 12F675 that requires VPP to be reached before VDD is on.

I can't explain it either, as I don't have a logic analyzer handy. My old analog o'scope doesn't have a store facility, so for single events like this, it's extremely difficult to see the start of events. However, I have now repeatedly read, erased, verified blank, read blank (all 3FFFs), and re-programmed this little PIC12F675 several dozen times. It is not what I would call an exhaustive test, however it does appear to be working.

R4.C3 time (10µS) is far shorter than the time of C1 or C2 with the line resistance (at least 100mS) so it cannot delay significantly VDD compared to the slow raising of VPP.

If you succeed to program your PIC12F629 I suppose I there is a trick that allows VDD to stay low. I don't understand the role of R5
R5 ensures that Q3 is turned off unless Vpp is low.
or why R3 is so low
Interesting point. I don't see a reason why both can't be increased by 5x or 10x.
...and I am concerned by the reverse voltage on Q3 base when VPP is on.
That problem could be reduced/eliminated by changing R3 / R5 values to be closer to equal, another good point.
But the trick does not seem to be around there, because I just see a transistor that prevents VDD to go significantly above VPP, but nothing that brings VDD below VPP.
Well, I'm getting around 5v on Vdd and around 12.5v on Vpp, so that portion does seem to be working.

In fact I believe that this schema can only rely on the incapacity for the serial line to pull more current from low RTS than it can push on high TxD, even when the average voltage of those inputs is higher than serial port ground. I am not sure that this is written in RS232 spec and that all port implementations will work with it. But if it works with yours that's fine.

Now to solve the issue about the raising time for VPP and VDD, I checked in WxPic and I saw, specifically for the JDM2 interface, that the delay after switch on is hard-coded and its value is 260mS. So to try to solve your blocking issue (and to know if it's actually the issue) I have modified this value to set 500mS and I have regenerated the executable. You can get this patch here. Uncompress with 7-Zip and replace WxPic.exe in your WxPic installation directory with the new executable. There is no other change from V1.2.1 in this binary (except the auto-generated version identification).


Thanks very kindly. I suppose I'll try swapping the previous 100uF caps back in with this new mod sometime this evening, or perhaps tomorrow.

To be frank, I never tried to model this programmer in SPICE, or any other "real" analysis on it.
Wook
 
Posts: 7
Joined: 18, 2010 Feb Thu 6:24 pm

Re: Problems with JDM2-type programmer and WxPic

Postby togum » 05, 2010 May Wed 7:47 pm

I have Problems of error in winpic, the programmer that I use is JDM2, I mounted 4 models jdm of different authors from the web, all the same error.

Operating system Microsoft Windows XP Professional
Version 5.1.2600 Service Pack 3 Compilation 2600
I model of the system KM400-8235
Processor x86 Family 6 Model 7 Stepping 0 AuthenticAMD ~1100 Mhz
Total physical memory 512,00 MB
Available physical memory 300,13 MB
Total virtual memory 2,00 GB
Available virtual memory 1,96 GB
I space of the pagination file 1,22 GB

Wx Pic

15:29:48.187 Info: Loading definitions for "PIC16F84A" from C:\Arquivos de programas\WxPic\devices.ini .
15:29:48.187 Info: PIC16F84A added and tested by FENG3
15:29:48.187 Parsed "C:\Arquivos de programas\Microchip\MPLAB IDE\Device\PIC16F84A.dev" : found 10 bit combinations in 4 configuration bit groups .
15:29:48.390 Initialising PIC-Programmer: Success.
Testing: delay(500ms) took 0.50 seconds, timer_freq=3.5795 MHz ... ok
15:31:39.765 Programming...
15:31:39.765 Erasing ("bulk" or "chip") ...
15:31:40.218 Programming and Verifying CODE, 0x000000..0x000121
15:31:40.437 Verify Error: 000000: read 003FFF, wanted 00018C
15:31:40.453 Verify Error: 000001: read 003FFF, wanted 00019D
15:31:40.468 Verify Error: 000002: read 003FFF, wanted 00018F
15:31:40.484 Verify Error: 000003: read 003FFF, wanted 000190
15:31:40.546 Verify Error: 000004: read 003FFF, wanted 000191
15:31:40.562 Verify Error: 000005: read 003FFF, wanted 000192
15:31:40.578 Verify Error: 000006: read 003FFF, wanted 000193
15:31:40.609 Verify Error: 000007: read 003FFF, wanted 000194
15:31:40.625 Verify Error: 000008: read 003FFF, wanted 000195
15:31:40.640 Verify Error: 000009: read 003FFF, wanted 000196
15:31:40.656 Verify Error: 00000A: read 003FFF, wanted 000198
15:31:40.671 Verify Error: 00000B: read 003FFF, wanted 000199
15:31:40.687 Verify Error: 00000C: read 003FFF, wanted 00019A
15:31:40.703 Verify Error: 00000D: read 003FFF, wanted 001683
15:31:40.718 Verify Error: 00000E: read 003FFF, wanted 003010
15:31:40.734 Verify Error: 00000F: read 003FFF, wanted 000085
15:31:40.750 Verify Error: 000010: read 003FFF, wanted 003000
15:31:40.750 Programming aborted after 17 errors.
15:31:40.953 Programming CONFIG, 0x002000..0x002007
15:31:41.187 Verify Error: 002007: read 003FFF, wanted 003FF1
15:31:41.406 ERROR: Programming FAILED !

Simulate only ( Ignore Hardware )

15:33:13.593 Info: Loading definitions for "PIC16F84A" from C:\Arquivos de programas\WxPic\devices.ini .
15:33:13.593 Info: PIC16F84A added and tested by FENG3
15:33:13.593 Parsed "C:\Arquivos de programas\Microchip\MPLAB IDE\Device\PIC16F84A.dev" : found 10 bit combinations in 4 configuration bit groups .
15:33:13.796 Initialising PIC-Programmer: Success.
Testing: delay(500ms) took 0.50 seconds, timer_freq=3.5795 MHz ... ok
15:34:12.00 Programming...
15:34:12.00 Erasing ("bulk" or "chip") ...
15:34:12.00 Programming and Verifying CODE, 0x000000..0x000121
15:34:16.578 Programming CONFIG, 0x002000..0x002007
15:34:16.703 Programming finished, no errors.

WinPic DL4YHF

Info: Loading definitions for "PIC16F84A" from C:\Arquivos de programas\WinPic\devices.ini .
Info: PIC16F84A added and tested by FENG3
Parsed "C:\Arquivos de programas\Microchip\MPLAB IDE\Device\PIC16F84A.dev" : found 10 bit combinations in 4 configuration bit groups .
Initialising PIC-Programmer: Success.
Testing: delay(500ms) took 0.50 seconds, timer_freq=3.5795 MHz ... ok
Programming...
Erasing ("bulk" or "chip") ...
Programming and Verifying CODE, 0x000000..0x000121
Verify Error: 000000: read 003FFF, wanted 00018C
Verify Error: 000001: read 003FFF, wanted 00019D
Verify Error: 000002: read 003FFF, wanted 00018F
Verify Error: 000003: read 003FFF, wanted 000190
Verify Error: 000004: read 003FFF, wanted 000191
Verify Error: 000005: read 003FFF, wanted 000192
Verify Error: 000006: read 003FFF, wanted 000193
Verify Error: 000007: read 003FFF, wanted 000194
Verify Error: 000008: read 003FFF, wanted 000195
Verify Error: 000009: read 003FFF, wanted 000196
Verify Error: 00000A: read 003FFF, wanted 000198
Verify Error: 00000B: read 003FFF, wanted 000199
Verify Error: 00000C: read 003FFF, wanted 00019A
Verify Error: 00000D: read 003FFF, wanted 001683
Verify Error: 00000E: read 003FFF, wanted 003010
Verify Error: 00000F: read 003FFF, wanted 000085
Verify Error: 000010: read 003FFF, wanted 003000
Programming aborted after 17 errors.
Programming CONFIG, 0x002000..0x002007
Verify Error: 002007: read 003FFF, wanted 003FF1
ERROR: Programming FAILED !

Simulate only ( Ignore Hardware )

Info: Loading definitions for "PIC16F84A" from C:\Arquivos de programas\WinPic\devices.ini .
Info: PIC16F84A added and tested by FENG3
Parsed "C:\Arquivos de programas\Microchip\MPLAB IDE\Device\PIC16F84A.dev" : found 10 bit combinations in 4 configuration bit groups .
Initialising PIC-Programmer: Success.
Testing: delay(500ms) took 0.50 seconds, timer_freq=3.5795 MHz ... ok
Programming...
Erasing ("bulk" or "chip") ...
Programming and Verifying CODE, 0x000000..0x000121
Programming CONFIG, 0x002000..0x002007
Programming finished, no errors.

WinPic800

ERROR- Writing address 0x000000
Written: 0x018C Read: 0x3FFF

Icprog

Verify Failed at address 0000h
togum
 
Posts: 1
Joined: 02, 2010 Apr Fri 9:32 am

Re: Problems with JDM2-type programmer and WxPic

Postby admin » 11, 2010 May Tue 9:48 pm

Well I am not sure I understand the problem. If you mean that you tried your JDM2 Hardware with 4 different Programming Software getting almost the same error, I supposed WxPic is not the root cause of the problem.
So what can I say? From my previous experiences with PIC controllers I can suppose that the PIC16F84A did not enter in programming mode due to VPP and/or VDD raising issue. The cause may be an incorrect programmer (bad mounting?) or an anemic serial port. Cannot tell you anything more.
admin
Site Admin
 
Posts: 153
Joined: 12, 2009 Jul Sun 7:20 pm


Return to WxPic Usage

cron