Reply by Phil Seakins ●December 17, 20032003-12-17
Jeff,

Bojan has just published another update, ver 0.15a, on Dec 10th. There was
one version which I found would not work on my 1.8gig desktop, I didn't
have time to investigate and instead used an already working configuration
on my laptop. It's worth sticking with this software, IMHO, because it has
some nifty features ie., automatically reloads the hex file when you do a
fresh compile and the PIC type can be defined by using a comment in the hex
file, serial number incrementing etc.

BTW, for all members using the P16PRO40 board, there is a flaw in the
original design which reverse biases the red LEDs with voltage bled from
vpp via the green LED. As most common LED's are only rated to withstand 5v
reverse potential (surprisingly) this can cause a breakdown (something like
a zener effect) resulting in very strange behaviour. Ie., programming
target address offset by one or two locations and/or not programming at
all. As far as I know there was no errata published for this.

Phil Seakins. At 12:17 PM 17/12/03, you wrote:
>I finally got things working, so I thought I'd follow up and close
>out this thread.
>
>As it turns out, the P16PRO board was fine, and so was my PIC chip.
>The problem was with the PICALL software - it simply didn't work for
>anything I tried. My solution was to use IC-PROG from www.ic-
>prog.com, and the trick to use it was to change the settings
>to "ProPic2 programmer" and to check the first three boxes - Invert
>Data Out, Invert Data In, and Invert Clock. The setup page is here:
>http://www.ic-prog.com/kit96_119set.html
>
>I hope this can help others having the same problem. Everything works
>fine now on both my slow old P1 laptop and my AMD 2500+ machine.
>
>-Jeff >--- In , "Jeff Swayze" <jswayze@o...> wrote:
>> Phil, thanks for your suggestions and for taking the time to
>respond. I tried what you
>> suggested, but unfortunately I'm experiencing the same problem.
>>
>> I found an 18v wall wart and used it to power the system. I also
>set both timing boxes
>> to 8000. When I clicked "Program" (things took a while to happen) I
>got the
>> "Programming device" window with "0000", then the red programming
>LED came on
>> on the board, then shortly after I got the now-familiar "Program
>Error" message.
>>
>> I ordered another board and chip from amazon electronics today, so
>I will be able to
>> do some comparisons once it comes in. Maybe I have a bad PIC chip?
>I don't know,
>> but this is quite frustrating.
>>
>> Thanks again for your help.
>>
>> Jeff
> >to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



Reply by ●December 16, 20032003-12-16
I finally got things working, so I thought I'd follow up and close
out this thread.

As it turns out, the P16PRO board was fine, and so was my PIC chip.
The problem was with the PICALL software - it simply didn't work for
anything I tried. My solution was to use IC-PROG from www.ic-
prog.com, and the trick to use it was to change the settings
to "ProPic2 programmer" and to check the first three boxes - Invert
Data Out, Invert Data In, and Invert Clock. The setup page is here:
http://www.ic-prog.com/kit96_119set.html

I hope this can help others having the same problem. Everything works
fine now on both my slow old P1 laptop and my AMD 2500+ machine.

-Jeff --- In , "Jeff Swayze" <jswayze@o...> wrote:
> Phil, thanks for your suggestions and for taking the time to
respond. I tried what you
> suggested, but unfortunately I'm experiencing the same problem.
>
> I found an 18v wall wart and used it to power the system. I also
set both timing boxes
> to 8000. When I clicked "Program" (things took a while to happen) I
got the
> "Programming device" window with "0000", then the red programming
LED came on
> on the board, then shortly after I got the now-familiar "Program
Error" message.
>
> I ordered another board and chip from amazon electronics today, so
I will be able to
> do some comparisons once it comes in. Maybe I have a bad PIC chip?
I don't know,
> but this is quite frustrating.
>
> Thanks again for your help.
>
> Jeff
>
Reply by Jeff Swayze ●December 6, 20032003-12-06
Phil, thanks for your suggestions and for taking the time to respond. I tried what you
suggested, but unfortunately I'm experiencing the same problem.

I found an 18v wall wart and used it to power the system. I also set both timing boxes
to 8000. When I clicked "Program" (things took a while to happen) I got the
"Programming device" window with "0000", then the red programming LED came on
on the board, then shortly after I got the now-familiar "Program Error" message.

I ordered another board and chip from amazon electronics today, so I will be able to
do some comparisons once it comes in. Maybe I have a bad PIC chip? I don't know,
but this is quite frustrating.

Thanks again for your help.

Jeff

--- In , Phil Seakins <pseakins@m...> wrote:
> It is "normal" for the P16PRO40 to appear to work correctly with no PIC in
> the socket and no hex file loaded. This is because the erased condition is
> all ones and so is an "empty" file. The software/hardware diddles with the
> control pins on the PIC and then assembles the bits read out of it into
> bytes. If there is no chip there all the bits read are high.
>
> In the PICALL/P16PRO software you should additionally check that you have
> specified the correct P16PRO board. Under setting/hardware setup you need
> to select the correct interface chip type - 74LS05, 06 or 07 depending on
> what is installed on your P16PRO40 board. Most importantly you need to
> ensure the timing value is adequate. Uncheck the AutoAdjust button and put
> in a ridiculously high timing value such as 8000 and see if it works then.
> I've had a lot of trouble with this on newer machines and Bojan has made
> several adjustments to the software to accommodate faster machines. It's
> also helpful if you have an already programmed chip, you can attempt to
> read its contents.
>
> I haven't checked the specs but 30V sounds a bit high. I would feel safer
> with 14 to 20 volts. Yes, it gets dropped down through regulators but this
> places a bit of a strain on them. (In my opinion).
>
> BTW, there is always much talk about the length of the parallel cable being
> critical. In my experience I've found it really doesn't matter. When I was
> developing a project some time ago I was using a twenty foot ribbon cable
> via a passive ABCD switch box and further six foot or longer cables with no
> apparent problems with the PIC burner or high speed data transfers using
> laplink and the like. The project I developed used the parallel cable for
> communication and I did many speed tests.
>
> Phil Seakins. > At 02:25 AM 6/12/03, you wrote:
> >I'm just starting out with PIC programming and bought a "built and
> >tested" P16PRO40 programmer board from Amazon Electronics. I found a
> >simple LED flasher hex file and attempted to load it into the 16F84A
> >that I purchased with the board. Obviously it didn't work since I'm
> >writing this message, but I'm trying to determine whether the
> >problem is with my technique or with the programmer. I'm using the
> >PICALL software from picallw.com, but I've tried 3 other free
> >programmers and have had similar results. Here are some points to
> >consider:
> >
> >- Programmer tests out ok - ie, correct voltages, is hooked up to
> >parallel port correctly, etc. Parallel cable is 3' long, input
> >voltage is 30v DC.
> >- Software is set for "P16PRO" and "PIC16F84A"
> >- If I hit the "Program" button with NO chip in the socket and NO
> >code in memory (code window shows 3FFF 3FFF 3FFF... etc.) it hums
> >along and says Programming...., then Verifying... and then says that
> >programming was completed sucessfully! With no chip in the socket!
> >- If I load the sample hex file into memory then try to program, I
> >get an error window right away titled "Verify" that shows: Program
> >Error / Program: address00 buffer000 device?FF
> >- If I click the "Verify" button, I get the same message as above
> >except it reads "Verify Error"
> >- Clicking "Erase" works without errors
> >- Clicking "Read" fills the program area with 3FFF's
> >
> >I guess the biggie for me is the fact that the board thinks
> >everything is hunky-dorey when there's no PIC in the socket. How can
> >it "verify" successfully with no PIC present?
> >
> >However, I'm open to other interpretations. I just need to know
> >whether to try to get a replacement board or not. I've done every
> >search I can think of and found several old messages describing
> >similar problems, but I've yet to hear a good solution.
> >
> >The closest thing I've found to a solution is talk of adding caps or
> >resistors to certain pins to help with faster machines, but I've
> >tried the software/hardware on an old Pentium I laptop as well as my
> >AMD 1.8 GHz machine with all the same results.
> >
> >I hope I didn't ramble too much. Thanks in advance for your insight.
> >
> >-Jeff


Reply by Phil Seakins ●December 5, 20032003-12-05
It is "normal" for the P16PRO40 to appear to work correctly with no PIC in
the socket and no hex file loaded. This is because the erased condition is
all ones and so is an "empty" file. The software/hardware diddles with the
control pins on the PIC and then assembles the bits read out of it into
bytes. If there is no chip there all the bits read are high.

In the PICALL/P16PRO software you should additionally check that you have
specified the correct P16PRO board. Under setting/hardware setup you need
to select the correct interface chip type - 74LS05, 06 or 07 depending on
what is installed on your P16PRO40 board. Most importantly you need to
ensure the timing value is adequate. Uncheck the AutoAdjust button and put
in a ridiculously high timing value such as 8000 and see if it works then.
I've had a lot of trouble with this on newer machines and Bojan has made
several adjustments to the software to accommodate faster machines. It's
also helpful if you have an already programmed chip, you can attempt to
read its contents.

I haven't checked the specs but 30V sounds a bit high. I would feel safer
with 14 to 20 volts. Yes, it gets dropped down through regulators but this
places a bit of a strain on them. (In my opinion).

BTW, there is always much talk about the length of the parallel cable being
critical. In my experience I've found it really doesn't matter. When I was
developing a project some time ago I was using a twenty foot ribbon cable
via a passive ABCD switch box and further six foot or longer cables with no
apparent problems with the PIC burner or high speed data transfers using
laplink and the like. The project I developed used the parallel cable for
communication and I did many speed tests.

Phil Seakins. At 02:25 AM 6/12/03, you wrote:
>I'm just starting out with PIC programming and bought a "built and
>tested" P16PRO40 programmer board from Amazon Electronics. I found a
>simple LED flasher hex file and attempted to load it into the 16F84A
>that I purchased with the board. Obviously it didn't work since I'm
>writing this message, but I'm trying to determine whether the
>problem is with my technique or with the programmer. I'm using the
>PICALL software from picallw.com, but I've tried 3 other free
>programmers and have had similar results. Here are some points to
>consider:
>
>- Programmer tests out ok - ie, correct voltages, is hooked up to
>parallel port correctly, etc. Parallel cable is 3' long, input
>voltage is 30v DC.
>- Software is set for "P16PRO" and "PIC16F84A"
>- If I hit the "Program" button with NO chip in the socket and NO
>code in memory (code window shows 3FFF 3FFF 3FFF... etc.) it hums
>along and says Programming...., then Verifying... and then says that
>programming was completed sucessfully! With no chip in the socket!
>- If I load the sample hex file into memory then try to program, I
>get an error window right away titled "Verify" that shows: Program
>Error / Program: address00 buffer000 device?FF
>- If I click the "Verify" button, I get the same message as above
>except it reads "Verify Error"
>- Clicking "Erase" works without errors
>- Clicking "Read" fills the program area with 3FFF's
>
>I guess the biggie for me is the fact that the board thinks
>everything is hunky-dorey when there's no PIC in the socket. How can
>it "verify" successfully with no PIC present?
>
>However, I'm open to other interpretations. I just need to know
>whether to try to get a replacement board or not. I've done every
>search I can think of and found several old messages describing
>similar problems, but I've yet to hear a good solution.
>
>The closest thing I've found to a solution is talk of adding caps or
>resistors to certain pins to help with faster machines, but I've
>tried the software/hardware on an old Pentium I laptop as well as my
>AMD 1.8 GHz machine with all the same results.
>
>I hope I didn't ramble too much. Thanks in advance for your insight.
>
>-Jeff
Reply by Jeff Swayze ●December 5, 20032003-12-05
I'm just starting out with PIC programming and bought a "built and
tested" P16PRO40 programmer board from Amazon Electronics. I found a
simple LED flasher hex file and attempted to load it into the 16F84A
that I purchased with the board. Obviously it didn't work since I'm
writing this message, but I'm trying to determine whether the
problem is with my technique or with the programmer. I'm using the
PICALL software from picallw.com, but I've tried 3 other free
programmers and have had similar results. Here are some points to
consider:

- Programmer tests out ok - ie, correct voltages, is hooked up to
parallel port correctly, etc. Parallel cable is 3' long, input
voltage is 30v DC.
- Software is set for "P16PRO" and "PIC16F84A"
- If I hit the "Program" button with NO chip in the socket and NO
code in memory (code window shows 3FFF 3FFF 3FFF... etc.) it hums
along and says Programming...., then Verifying... and then says that
programming was completed sucessfully! With no chip in the socket!
- If I load the sample hex file into memory then try to program, I
get an error window right away titled "Verify" that shows: Program
Error / Program: address00 buffer000 device?FF
- If I click the "Verify" button, I get the same message as above
except it reads "Verify Error"
- Clicking "Erase" works without errors
- Clicking "Read" fills the program area with 3FFF's

I guess the biggie for me is the fact that the board thinks
everything is hunky-dorey when there's no PIC in the socket. How can
it "verify" successfully with no PIC present?

However, I'm open to other interpretations. I just need to know
whether to try to get a replacement board or not. I've done every
search I can think of and found several old messages describing
similar problems, but I've yet to hear a good solution.

The closest thing I've found to a solution is talk of adding caps or
resistors to certain pins to help with faster machines, but I've
tried the software/hardware on an old Pentium I laptop as well as my
AMD 1.8 GHz machine with all the same results.

I hope I didn't ramble too much. Thanks in advance for your insight.

-Jeff