On Mon, Jul 22, 2002 at 09:30:43PM -0400, Jai Dhar wrote:
> Hi,
>=20
> Despite all the help received, I'm still having problems.. so I will expl=
ain what I'm EXACTLY doing.
>=20
> I start off with almost 0V on the MCLR pin, and all power off. I then app=
ly +5V to Vdd and +12V to MCLR simultaneously. After that, I run my program:
>=20

Are both RB6/CLK and RB7/DATA both low at the point that you transition MCLR
from 0V to Vpp? If not you don't get programming mode.

> printf("Issuing write command with data\n");
> sendbyte(6,2,fd);
> sendbyte(1,0,fd);
> sendbyte(8,5,fd);
> sendbyte(6,0x28,fd);
> sendbyte(1,0,fd);
>=20
> printf("Issuing program cycle command\n");
> sendbyte(6,8,fd);
>=20
> printf("Issuing read command\n");
> sendbyte(6,4,fd);
> sendbyte(1,0,fd);
> printf("Reading data now...\n");
> sendbyte(8,0,fd);
> sendbyte(6,0,fd);
> sendbyte(1,0,fd);
>=20
> sendbyte is defined to be a function that sends a certain number of bits =
(I know, naming doesn't make sense) that sends x bits of the number specifi=
ed in the second param.. and yes, it sends  them in the correct order. So o=
n the reading data part, I send 6 bits of 0x04 to issue a read command, and=
 then a start bit. And then, I send out 14 bits of just clocking while read=
ing the pin via parport (the sendbyte command also reads the status of RB7)=
. And then finally, a stop bit. The CLK and Data lines are passed through a=
 buffer and then connected to RB6/RB7, and RB7 also goes to the input of a =
buffer, which goes into the status port of the parport so I can read it eas=
ily. So.. what seems wrong? I have a feeling now that it's the MCLR issue, =
I'm not sure though. I read the code lowlvl.c, and my algorithm is exactly =
the same after the config. data is entered and the PC is incremented. But t=
his doesn't seem that it should matter in my simple situation. Ugh.. I'm ge=
tting fustrated!
>=20

I'm still concerned with the hardware. What kind of buffer are you using?
What are you using to keep the output buffer from the parallel port from=20
colliding with the output buffer of the RB7/DATA pin?=20

> Help!!

Test your hardware with some existing working software and rule out all of =
the
hardware issues. If your hardware works with FPP or picprg and doesn't work
with your code, then you can pinpoint the problems. However from your=20
description above, you may still have issues with your hardware.

Dumb question: Did you change 16F84s after putting in the buffers? As I sai=
d=20
in a previous post, it's possible that you blew out the buffers for RB7/DAT=
A =20
by connecting it directly to the parallel port output.

The tough part about bootstrapping a PIC programming algorithm is that you=
=20
don't know if you're on the right track until you can get the PIC to accept
a read command and get it to flip RB7/DATA from an input to an output.

Lastly don't bother programming anything yet as it isn't a relevant activity
to getting the interface right. Get your hardware to the point where you can
clearly separate the buffer going into RB7/DATA from the data coming out of
that pin. Then just work on getting it to read. If you can get the RB7 pin
to turn into an output, then you've got it.

BAJ

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.