Fox Delta Programmer Quit working

[ClydeCrashKop]

I bought a Fox Delta Parallel Port PIC Programmer and use WinPicPro beta. It has been working fine until today. Now it will not reprogram a 16F628A. It will program a new one. I get verify error at address 0X00. I never saw the green light come on until today. It has 13 volts at VPP. It has a 7405 and is set for 7406 and the LPT1 address is right. Any ideas?

 

[Ambient]

Would enabling code protection do that? Or maybe the chip got damaged? That is the only thing I can think of. Doesn't sound like a hardware problem if it programs a new one fine.

 

[ClydeCrashKop]

No code protection, no fuses blown. Just a modified version of Nigel's LCD tutorial. 3 different chips. (I may have hurt RB7 on one of them) hehehe. I have been able to reprogram after code protection and fuses blown in the past but these were virgin.

 

[Mike - K8LH]

The only problem I had with a similar programmer (long ago) was trying to use a standard 6 foot parallel cable. I built and used an 18 inch cable and never had any problems...

Good luck. Mike

 

[Nigel Goodwin]

Have you got the 628 set to use the internal oscillator?.

If so, try reducing Vpp delay in WinPicprog.

 

[ClydeCrashKop]

Thanks Nigel, but that didn’t seem to help. I do have another couple of clues. If I READ PIC, it comes back full of 3FFFs. Then if I VERIFY, I don’t get the error and it says very successful.. The previous program is still in there and still works. It doesn’t erase either. Shouldn’t it erase before programming?
The data going to the PIC had 4 to 5 volt oscillations when it should be high. No oscillations from LPT1.
I couldn’t imagine why they would want a capacitor on the data line so I removed it. It still has 4 to 5 volt oscillations but they are almost square. That data signal gets inverted again and is sent back to the PC but with no oscillations. (filtered out by 74LS05 ?)

 

[ClydeCrashKop]

I got it working with the Oshonsoft program but it is still a little flaky. I put the cap back in and it still works. I think I will make a short cable when I get a chance, or the next time I am on a roll with circuit building and ASM programming and this thing brings me to a screeching halt.
Thanks guys

 

[Nigel Goodwin]

Thanks Nigel, but that didn’t seem to help. I do have another couple of clues. If I READ PIC, it comes back full of 3FFFs. Then if I VERIFY, I don’t get the error and it says very successful.

If you remove the PIC it should read all 3FFF, that's what a completely blanl PIC should read, or if ones not there, or if it's not getting switched to programming mode.

The previous program is still in there and still works. It doesn’t erase either. Shouldn’t it erase before programming?

Yes it should (and does) - check your Vpp voltage, it should be about 13V and ripple free.

 

[ClydeCrashKop]

Problem solved. This being the first time I used timer1, I mistakenly or accidentally set the T1CON, T1OSCEN bit enabling the oscillator. I also set RB7 as output to control a data selector for 2 frequencies at RB6. The result was clock pulses being sent out on RB7, (not mine) so when the programmer was sending data to RB7, RB7 was talking instead of listening so the PIC and programmer were butting heads and would not reprogram. The book didn’t explain this so it is probably not a logical configuration under any circumstances. Oscillator enabled, EXT CLOCK, not synced, on T1CKI pin.
I got all 3 chips erased with the Oshonsoft program, bit cleared and everything is working fine again.

 

[eblc1388]

You have attributed your problem to the code that you have previously placed into the PIC. But your are certainly not correct.

When a PIC is being properly reset and put into programming mode, what the user has previously programmed into the PIC code memory would not matter. In the programming mode the PIC is NOT running any user code at all.

 

[Nigel Goodwin]

You have attributed your problem to the code that you have previously placed into the PIC. But your are certainly not correct.

When a PIC is being properly reset and put into programming mode, what the user has previously programmed into the PIC code memory would not matter. In the programming mode the PIC is NOT running any user code at all.

Correct, his reason doesn't make any sense, what it most likely was (and why I asked if he was using the internal oscillator), is that the PIC was actually running - and if it's running you can't enter programming mode.

So it's essential that you enter programming mode very quickly, before it has time to start running. WinPicProg has an adjustable delay called 'Vpp Delay' which sets the length of time (in milliseconds) between setting Vdd high, and Vpp to 13V - if it's too high, you can't enter programming mode when you have the internal oscillator selected.

 

[ClydeCrashKop]

I am using the internal oscillator. It could be a timing thing. I did reduce the delay like you suggested but probably no less than 5.
I guess I should expect more gremlins in the future then.

 

[Nigel Goodwin]

I am using the internal oscillator. It could be a timing thing. I did reduce the delay like you suggested but probably no less than 5.
I guess I should expect more gremlins in the future then.

Not once you've reduced Vpp delay to a low enough value!, you might also consider setting the PUT in the config fuses, this means it takes longer before it runs.

 

[ClydeCrashKop]

The 4 to 5 volt oscillations when programming on RB7 are gone now. I see real data on the scope now when programming every time.
Thanks Nigel. Will do.