Warning: I am new.  I have searched the archives, and read much
information looking for answers.  I successfully programmed a 16F84A,
once, a few years ago, and it did some LED blinking, but much time
(and lost memory) has passed since then.

Now that that's out of the way...

I have been going through the "Elmer 160" course, and I am at the
point where it's time to start putting code onto a chip, and making it
do something to interact with the real world.  This is exciting!  The
not so exciting part, of course, is failing to get the code onto the
PIC.  Heeding the advice of just about everything I have read, I have
been working with a 16F628A intead of the 'F84.

I have built one of BAJ's THVP's, but have not quite had luck with it
yet, at least not using FPP to talk through it to a PIC.  Using a
multimeter, and twiddling with the test knobs within FPP, the THVP
seems to be wired right.  It wasn't, at first, and the multimeter
showed me this.  Having fixed the issue, I see all the pins go high
and low as expected.  Trying to push code to the PIC through FPP
results *immediately* in FPP telling me "Failed to program code!".  It
does claim to successfully erase the PIC, and read the PIC (comes back
with "-- Blank --").  The archives showed me that Konstantin had had
this come up before... I hope I don't become a Konstantin (no
offense)!  Anyway, the three bits I got out of the archives were to
check the programmer with a multimeter (done, checks out), to make
sure that giveio.sys is in and working (should be, I can twiddle the
test knobs in FPP and check with a multimeter) and to use a shorter
cable.  The THVP has the long cable termination bits in it, but just
for S&G's I jacked the programmer directly into my parallel port (no
cable).  It acts the same way.  FPP has some default pinouts for the
TLVP, which I tried selecting and inverting MCLR, and they check out
equally well with the multimeter but show no success when programming.
 It looks like the FPP config for TLVP is nearly identical to what is
needed for THVP.. just remove PGM (unnecessary for THVP), and invert
MCLR.  An even more interesting bit, is that FPP shows the same
programming results when I disconnect the THVP: fails to program
immediately, but also successfully erases and reads (or so it claims
anyway).

So, now, to rule out more bits (read: Windows), I feel I would like to
try to program the pic from my linux box.  Since BAJ is (according to
the archives) using 'picprg' under linux, and the THVP is his twist on
the Tait design, I figure it's a good mix to try. I have picprg3.0 all
nicely compiled, installed and not complaining about /dev/lp0.
picprg3.0 claims it can dump code onto all PICs, which at the least I
would hope would cover my 'F628A.  When I start picprg, I go into it's
config settings and set it to talk to the right parallel port pins for
the THVP (inverting MCLR too).  Having done that, I load a very simple
inhx8m style .hex file created by mplab.  It is after this that I am
bothered (discouraged from trying to put code on the PIC), and here is
why:

My config line in the .asm is as follows:

__config	_HS_OSC & _WDT_OFF & _PWRTE_ON & _CP_OFF & _LVP_OFF

picprg seems pretty fancy, in that it reads the config bits, and
displays them across the top for you in something human readable (not
just "3F62").  When I start it up, and have no .hex loaded, it says:

CLOCK: RC  PIC RAM: 0xc00                           CP: OFF  WD: ON   PU: ON

I load my .hex, and it changes:

CLOCK: HS  PIC RAM: 0xc00                           CP: ON   WD: OFF  PU: OFF

Wait, WHAT?!  I said "_CP_OFF" and "_PWRTE_ON"... why does this show
the opposite?  It did pick up on my using _HS_OSC instead of RC, so
it's figured something out, but why did it seem to get CP and PU
wrong?

To try to troubleshoot this a bit more, I changed the .asm to reflect
an 'F84, since picprg was originally written only to program them
(well, 'C84's anyway...).  I changed the config bits several times
within the 'F84 .asm, recompiling the .hex, and loading it into
picprg.  Each time, picprg got the config bits right for the 'F84.
Maybe it's display across the top is not up to date with displaying
config bits for PIC's other than the '84, and I should trust that it
will push the right code (including config bits) to the PIC,
regardless of what it shows across the top?

I did learn that I need to manually update .picprgrc and set PIC_size
for whatever type of PIC I'm trying to program at the moment (I might
wrap a shellscript around launching picprog to ask/remind me of this).
 That should take care of correcting "PIC RAM: 0xc00."  I just don't
feel comfortable asking it to write this stuff out to the PIC until I
understand why it seems to be reporting config bits incorrectly.

Thoughts?

TIA,

-detrick
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist